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GENERALIZED ORGANIZATION OF LARGE DATA-BASES; 
A SET-THEORETIC APPROACH TO RELATIONS* 


Abstract 


Problems inherent in representation and manipulation 
of large data-bases are discussed. Data management is 
considered as the manipulation of relationships among 
elements of a data-base. A detailed analogy introduces 
concepts embodied in a data management system. Set theory 
is used to describe a model for data-bases, and operations 
suitable for manipulation of relations are defined. The 
architecture chosen for an implementation of the model is 
illustrated, and a representation of data-bases is suggested. 
A particular implementation, the GOLD STAR system, is inves- 
tigated and evaluated. The framework outlined is meant to 
provide an environment in which complex data handling prob- 
lems can be solved with relative ease. GOLD STAR provides 
the user with tools sufficient for manipulation of arbi- 
trarily complex data-bases; these provisions are presented 
in the form of an extremely simple interface. 


*This report reproduces a thesis of the same title 
submitted to the Department of Electrical Engineering, 
Massachusetts Institute of Technology, in partial 
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Bachelor of Science and Master of Science. 
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CHAPTER I 
INTRODUCTION 


The M.I.T. Electrical Engineering Department, like 
other large organizations, requires a powerful data manage- 
ment capability to provide information for daily operation. 
The department currently utilizes a software system developed 


by Burton J. smithit 4 


which operates on the M.I.T. Compatible 
Time-Sharing System. Faced with the burden of manual gener- 
ation of teaching and research assignments, budget reports, 
Mailing labels, and other documents, the department began 

in 1966 to transfer these tasks to the CTSS system with a 
significant saving in production time, personnel effort, 

and cost. With the forthcoming demise of the 7094 CTSS 
installation, an alternative computer system is needed, 

and provides the motivation for this thesis. 

For any integrated information system, the flexibility, 
and hence the scope of its utility, depends heavily upon the 
sophistication of its associated data management system. 
While this term connotes the existence of various functions 
to different individuals, the prime purpose of such an 
entity is to provide a coherent and systematic method of 
manipulating large volumes of interrelated data. Such a 
purpose is laudable, but only if a user can avail himself 
of the capability in a manner which makes the results, as 


well as the process, meaningful to him. 
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Our concern in this thesis is the development of a data 
Management facility capable of serving a wide variety of 
administrative information needs. Specifically the system 


characteristics are: 


1. Pre-eminence of User Perspectives and Techniques. 
A data management system is most effective when a 
user Can express his problem to the system in terms 
of his perspective and biases; to the faculty planner, 
data types such as ''name", "salary", and "project" 
hold much more meaning than representation types like 
INTEGER, DECIMAL, or BIT. For the same user, the 
operation "SORT (PHONE BOOK, (TEL, NAME, ADDR))" 
expresses his purpose more than the effort required 
to write his own sorting routine. A good data man- 
agement system will minimize the degree to which a 
user alters his perception of, and approach to, his 


information problems. 


2. Modular Construction. 
While extensive planning of a system is advisable 
before development, experience indicates that soft- 
ware systems evolve with time rather than merely 
exist. That is, pre-planning a system rarely 
encompasses all features that may be desired at 
some unknown point in the future. A system should 


be modular in the sense that features added or 
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deleted in the evolution process disturb only local 
portions of the system. Modularity obviates the 


need for redesign and re-programming at each change. 


3. Exportability 
An organization may change the computer system it 
utilizes for data processing, but such a change 
should not disrupt the operation of the firm or 
division. While few computer programs are machine 
independent, a data management system can attain a 
high degree of exportability or relative machine 
independence, by isolating particular machine depen- 
dent features in a few modules. The remaining 
system modules should be written using a widely 
available higher level language. Design of a data 
Management system with this objective in mind mini- 
mizes the operational disruption occasioned by a 


change in the target computer. 


The goals outlined thus far apply to design philosophy; 
as such they pertain to all features which a data management 
system may exhibit. There are, however, more specific 
requirements placed upon any particular data management 
system, requirements dictated by the characteristic environ- 
ment in which the system must operate. The envisioned 
system is best suited to a "computer ueaTiae -enetroanene, 


and as such requires two further considerations: 
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Controlled Sharing Among Users 
A computer utility provides the services of computa- 
tion for a broad-based community of users. Since 
some information, such as salaries and grades, is 
often considered personally sensitive, it is of 
prime importance that only those members of the 
community who require this information be allowed 
access to it. The strategy of allowing a user to 
access only these relations he creates would largely 
protect the integrity of sensitive information. 
However, such an extreme requirement eliminates 
effective communication among users whose data 


purviews overlap. 


On-Line Capabilities 

Management of a department or office occasionally 
requires instantaneous access to the data-base. 

The ability to update files from a remote terminal 
is extremely convenient; data may be entered by a 
secretary as if she were typing a report, obviating 
the need for keypunching and physical handling of 
cards. llowever, the greatest need for on-line 
access arises when a user searches the data-base for 
specific facts, and based upon the computer's re- 
sponse, asks for any of a wide range of additional 


data. For example, the university bursar may ask 
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for student accounts showing a lapse of payment 
greater than 30 days, along with the total number 

of dollars receivable from students. If the total 
due were mostly a result of the overdue accounts, 
he could generate address labels for those students 
tardy in payment and send notices using these labels. 
Interaction of a user with his data-base in this 
fashion is a powerful administrative tool, and thus, 


a justification for on-line capabilities. 


The concurrent requirements of sharing and pre-eminence 
of user perceptions of relatedness present the sub-system 
designer with a formidable task. Vendors of software pack- 
ages offer a variety of solutions but almost all efforts 
focus on representation and manipulation of data elements. 
GOLD STAR (Generalized Organization of Large Data-bases; a 
Set Theoretic Approach to Relations), however, focuses upon 
the representation and manipulation of relations among data 
elements. This focus should be the prime function of any 
data management system. The functions of the GOLD STAR data 
Management system are: 1) to implement an arbitrary concep- 
tualization of relatedness among entries in a data base, 
and 2) to transform the specified operations on the data 
base into sequences of instructions which will produce the 
eftect of these operations. Thus the design intention of 
GOLD STAR is to remove, as far as possible, computer con- 


straints on the conceptualization of a data management 


-12- 
problem, while providing a direct means of mechanizing the 
same. 

Several methods of implementing such a system are possi- 
ble; in the first effort, GOLD STAR is imbedded within the 
PL/1 language as a set of function sub-programs. Imbedding 
allows the user full access to GOLD STAR without the burden 
of mastering some esoteric programming language; rather it 
extends the power of an established programming system to 
the realm of relation management. Imbedding permits imple- 
mentation of a model at low cost; the model's utility and 
power can be evaluated, as well as operated, without devel- 
opment of a special purpose compiler or interpreter. GOLD 
STAR assumes that calls to the imbedded functions are 
"primitives", i.e., a user need endure no greater complexity 
than these calls. GOLD STAR is written entirely in the PL/1 
programming language and its facilities are available to any 


program written in PL/1. 
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CHAPTER II 


To explain the data-management system developed in this 
thesis, we shall use an example designed to illustrate and 
motivate the system structure we have chosen. By introducing 
additional concepts to the analogy, it will be possible to 
explain all of the major issues of the GOLD STAR system. 
Following the example, we will relate the user's needs to 
the data-management system by both describing the general 
kinds of operations he might wish to perform, and the way 
in which the system conforms to the goals outlined in the 
Lirst: chapter. 

We assume that a small company has decided that it 
should establish a name-address-telephone number directory 
of its employees, although it has only eight employees. 

The preliminary, hand-written draft of the directory appears 
in Figure 2-lon the next page. 

This preliminary draft of the directory has some very 
important properties which should be noted. First, each 
line not only contains three items of information (ji.e., a 
name, an address, and a telephone number), but it states by 
its physical structure that each of these items is in a 
sense related, i.e., they "belong" to each other. Second, 
each item in the directory is associated, by its column, 


with a heading or type. Hence, '541-6622"' (a telephone 


Name 


Abernathy, Fred 
Barnes, John 
Donnelly, Bill 
Jones, Art 
Jones, Sally 
Manning, Pete 
Manning, Pete 
Parker, Irv 


Sanders, Doug 


Figure. 2°13 


PAS 


Address 


22 Maple Street 

13011 S. Weymouth Drive 
2 Wallingham Place 

53 Main Street 

53 Main Street 

264 Carling Avenue 

264 Carling Avenue 
1L0>-S« Pannert 


3 Mangrove Plaza 


Telephone 


78575055 
249-8112 
247-7731 
724=3718 
724-3718 
861-8366 
861-4431 
541-6622 


443-8190 


Preliminary Draft of Directory 
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number) would never be found in the same column as "Parker, 
Irv'' (a name). Third, the directory itself is characterized 
by the types it contains (in this case name-address-tele- 
phone). Finally, we note that the first column is in alpha- 
betical order. This makes a line easy to find when given a 
name. Hence, "Jones, Sally" is much easier to locate than 
is "861-8366", since the directory is ordered primarily by 
names rather than by telephone numbers. The left-to-right 
representation of the directory is usually used to imply 
that the further left we look, the more order a column pos- 
sesses. This is a convention adopted in most cases which 

is not innately necessary. 

Now let us complicate the problem -- a printing strike 
is in progress when the directory is to be published. Print- 
ing costs are very high, with charges figured on a per charac- 
ter basis. In assessing the alternatives, management real- 
izes that the company currently possesses a microfilm storage 
system for which each employee has a small console unit. 
These consoles each have an array of push-buttons which are 
used to display selected information on a screen. 

Management decides upon the following approach to make 
the directory available to the employees: the names, ad- 
dresses, and telephone numbers are placed on microfilm, and 
a list of which button is to be pressed on the consoles to 


retrieve information about which employee is readied for 
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printing. Thus, if you were to press the button "name" 
(this loads the 'name' cartridge), and then the button "1", 
"Abernathy, Fred'' would appear on the screen. In Figure 2-2 
we picture the information stored on microfilm as well as 
that printed. 

At this point the use of this directory is not neces- 
sarily clear. However, before considering how, we should 
observe a number of important concepts embodied by this 


change, and which motivate the change. 


1. The headings in the printed directory (Figure 2-2-d) 
are still necessary in order to know which car- 
tridge to load when information is requested. 

Thus an item of information is associated with 


both a button number and a (cartridge) type. 


2. The only association between these cartridges 
and this directory are through the headers (and 
corresponding cartridge types). The same "name" 
cartridge would be used as part of this company's 
name-department listing. Note that a saving is 
reaped for this second listing in that a new 


"name" cartridge would be unnecessary. 


GA 


Although one forms a mental picture of the 
contents of a cartridge such as is illustrated 
in the figure, we do not actually know how the 


information is physically stored. The extent 


meee 


Cartridge No. 1: Loaded by pressing "name" 


Button No. For Retrieval Information Retrieved 
1 Abernathy, Fred 
2 Barnes, John 
3 Donnelly, Bill 
4 Jones, Art 
5 Jones, Sally 
6 Manning, Pete 
7 Parker, Irv 
8 Sanders, Doug 


Figure 2-2-a: Name Console Cartridge 


Cartridge No. 2: Loaded by pressing 'address" 


Button No. For Retrieval Information Retrieved 
1 22 Maple Street 
2 13011 S. Weymouth Dr. 
5 2 Wallingham Place 
4 53 Main Street 
5 264 Carling Avenue 
6 10 S. Pannert 
7 3 Mangrove Plaza 


Figure 2-2-b: Address Console Cartridge 
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Cartridge No. 3: Loaded by pressing ''telephone number" 


Button No. For Retrieval Information Retrieved 
1 783-3055 
Z 249-8112 
5 247-7731 
4 724-3718 
5 861-8366 
6 861-4431 
7 541-6622 
8 443-8190 


Figure 2-2-c: Telephone Console Cartridge 


The Printed Directory 


Name Address Telephone Number 
1 1 1 
2 2 2 
3 S 3 
4 4 4 
S 4 4 
6 5 5 
6 5 6 
7 6 7 
8 7 8 


Figure 2-2-d: Printed Directory 
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of our knowledge is that we can perform two func- 
tions: we can press a numbered button (presumably 
we have already loaded the cartridge) and have the 
corresponding data item appear on our screen, or 
we can somehow type in a data item (the hardware 
is irrelevant) and have its button number appear 
on the screen. There is no reason to believe 
that names and addresses are stored in the same 
physical manner in the cartridges, despite the 
fact that the console performs identically for 


all corresponding requests. 


Some tasks become easier. In glancing over the 
directory, ‘Jones, Sally" will be more easily 
mistaken for "Jones, Art" than "5" will be for 
"4" In addition, comparisons are easier by 
mere virtue of the fact that directory entries 
are now a single number rather than a multi- 


character name (or address, etc.). 


There is an implied order on button numbers 
(numeric, of course). Hence, in the case of 
"name" numeric order on the button corresponds 
to the alphabetic order on the names. However, 
in the case of "address"', where no order was 
assumed in the beginning, the task of deter- 


mining the button number associated with a 
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given data item is a hard one -- all address 
entries must be checked (i.e., there is no 
guarantee of any relative positioning for the 


addresses). 


6. In cases where duplication of items occurs, 
large savings accrue from the given organi- 
zation. For example, although Pete Manning 
has two lines in the directory, all that must 
be printed twice is his button number. His 


name is stored only once on the'name" cartridge. 


7. The directory is meaningless out of context 
(i.e., with no headers). One would not know 
which cartridge to load before pressing the 
buttons for inquiry. 

In order to consider how the system is used, we take a 
name and request the associated address and telephone number. 
First, the "name'' button is pressed to load that cartridge. 
Then the desired name is inserted and the associated button 
number is read off the screen. Now we look in the printed 
directory for the line with that number in the name column 
and retrieve the other information by pressing the appropriate 
cartridge load button and number button. 

Note that we have said that the printed directory in 
this numeric form retains exactly the same properties as did 


the original listing with the complete text (Figure 2-1). 
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There are new considerations (as outlined above), but there 
are no conceptual differences in the information content of 
the two methods of representation. 

Let us now assume that negotiations in the printer's 
dispute have broken down altogether; now no printing services 
are available. Management can either wait for the printer's 
strike to end or seek an alternative. They decide on the 
following alternative: a new set of microfilm equipment is 
purchased, with each employee receiving a terminal (we shall 
distinguish these "terminals" from the previously discussed 
"consoles"). This new system (the terminal system) is to be 
employed to store the directory itself in a directory~car- 
tridge, which will be named, appropriately, ''name-address- 
telephone number". The facilities of the terminals must be 
more complex than the consoles in order to handle these more 
complex directory-cartridges. 

The terminals are capable of responding to requests such 
as ''display the line in name-address-telephone number con- 
taining "5" in the address column.” The request itself is not 
necessarily in English, but the key words corresponding to 
load directory (first "in''), locate line ("display"), look in 
a given column (second "in'), look in a given column for a 
given button number ("containing") correspond to buttons. In 
addition, the terminals are equipped with the ability to read 


and create magnetically inked listings of the directory car- 


tridges. 


Boe 


These listings are used to verify the entire con- 


tents of a directory cartridge, or to insert a new cartridge, 


or to make modifications, or other such operations. Note 


that the listings produced and read are in exactly the same 


format as the one in Figure 2-2-d., 


Now, again, we focus on some key considerations gener- 


ated by the change in our information storage arrangement. 


ds 


We still have no idea how a directory is physically 
stored on a directory-cartridge. We know only 
that the terminal can perform various tasks 
(which we will elaborate on later) on the 
directory-cartridges such as load them, inquire 
of them, and make a listing from them. The data 
items stored in these directory cartridges are 
the same button numbers which would have appeared 
in a printed directory (Figure 2-2-d)and are to be 
used on the consoles to obtain text from the 
screen. Further, there is no reason to assume 
that all directory cartridges have the same 


physical format. 


The logical structure used in different directory 
cartridges may be different. The "relatedness" 
implied by the line structure may be recorded 

in ways other than lines. The only requirement 


to be met by the other logical structures is 
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that they be capable of being translated into 
a listing of the form of Figure 2-2-d. For example, 
Pete Manning's two different telephone numbers 
may both be associated with his name and address 
in such a way that the name and address columns 
need be physically present only once for his 


hame. 


3. More than one directory-cartridge can be used 

in the terminal system. One such cartridge 

has no relationship to another. It is possible 
to have both "name-address-telephone number" 
and "name-department" cartridges, but the exis- 
tence of a given name in one says nothing about 
the existence of that name in the other (i.e., 
because a name possesses an address and number, 
we can determine no association between this 
name and any department). 

Now consider the kind of operations we might want to 
perform upon the directory-cartridge(s). If another company 
merged with this one and it used the same information system, 
we might want to merge the two "name-address-telephone number" 
directory cartridges to form one. Or, if an employee left, 
we might wish to remove all lines about him from a directory- 
cartridge. Or, we might wish to "combine" the 'name-address- 


telephone number" with '"name-department" to give a new "name- 


-24- 


department-address-telephone number" directory-cartridge. 
These are but a few of possible operations which we might 
want to perform. 

It would be premature at this time to discuss the full 
spectrum of operations we may wish to perform on the termi- 
nals and consoles. Rather, we extend our terminology by 
putting forth a general system structure for GOLD STAR and 
showing how the various components of the system correspond 
to our example. Then we may attempt to define at least the 
classes of operations we might do with the consoles and the 
terminals. The diagram of Figure 2-3, although it may seem 
cryptic at first, serves to characterize the GOLD STAR data 
management system. 

Now let us take the various blocks of the figure and 
discuss their function by referring to the example of the 


microfilm system. 


DSM (Data Strategy Module): These correspond to the 
consoles and serve to translate between the refer- 


ence numbers (the button numbers) and the data items. 


DA (Data Area): These correspond to the data cartridges 
which are part of the console system. Just as a but- 
ton must be pressed to load a cartridge, so must 
information be given to the DSM to tell it which DA 
to refer to when retrieving text or reference num- 


bers (refnos). This "load button" is what is 


PARSER OPTION ied 
DIRECT USE 


INDIRECT USE 
foes 


DSM RSN RSM 


4 


» } [}: ‘of. fe 


FIGURE 2-3 GOLD STAR system STRUCTURE 
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referred to as a data-type name. 


RSM (Relational Strategy Module): These correspond to 
the terminals and serve to perform operations on 
relational data just as the terminals perform oper- 


ations upon the directory-cartridges. 


RD (Relational Data): These are the directory-car- 
tridges of GOLD STAR. Just as the directory-car- 
tridge must be requested by name, so must an RD be 


requested via a relation name (or rel-name). 


QUART (QUAsi RelaTion): These are the listings of the 
terminals. All RSM's can produce quarts or can, in 
fact, convert the contents of an RD to a quart. 
These are the fundamental units of the system in 
that all modules of the system can deal in some way 


with quarts. 


MGR (Manager): There is no direct analogy to the mana- 
ger in the microfilm system. The manager is merely 
the module which has the effect of making button- 
pressing operations easier. It provides an easy 
language for the user to use in utilizing the avail- 


able powers of the DSM's and RSM's. 


CENT §& PENT: Two representations (character and 
pointer) of a header. The rest of the components 


serve much more specific tasks and will be discussed 


ay a 


in later sections. To briefly review the main con- 
cepts again, information text is stored only once 
and a token refno assigned to it. The information 
of how data items are related to one another is 
stored separately and is operated upon separately. 
This approach allows the savings and features men- 
tioned in the discussion of the example to be 
capitalized upon. 

Consider briefly the classes of operations which will 


be desired from our components. 


{Data-String} > {refno} 
DSM 
(2-1) 


This is the translation of text into its reference 
number (refno). We have assumed that the nature of 
the data string is known so that we can determine 
into which data area we must inquire. We have also 
assumed that each data area has one and only one 
DSM which can perform the indicated translations 
and that we can easily determine which DSM by 


looking in the data area. 


{refno} + {Data-String} 
DSM 


(2-2) 


This is the reverse of (2-1). The same assumptions 


hold true. It is worthwhile to note at this point 


A798 


that each reference number is stored as part of a 


quart; these quarts also contain information indi- 


cating the data area to which this refno refers. 


Thus, the specification of data area can be either 


implicit (found from the refno's quart) or explicit. 


{refno} + {refno} 
DSM 
(273) 


This is the way of representing a transformation 
through a DSM, such as "get the next refno after 
the one I supply". Again, the same assumptions 

as above hold, and data area can be implicity or 


explicitly indicated. 


{refno} + {refno} 
RSM 
(2-4) 


This indicates a transformation performed when 
information (in the form of refnos) is given to 
an RSM; what is returned is another bundle of 
information which has been found using the pro- 
perties of relatedness stored in a relation 
(relational data area). The appropriate RD and 
RSM are implicitly determined from a group of 
input refno quarts. 

{refno} + R 


RSM 
(2-5) 
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This is the same as (2-4) except that the result 


is a complete RD containing the properties of the 


transformed refno input. 


R > {refno} 
RSM 
(2-6) 
This is the reverse of (2-5). 
RR 
RSM (2-7) 


This is the transformation of one RD to another. 


A merge is an example of such an operation. 


These are the general classes of operations available 
to the user. The first three are those which would be per- 
formed on the console in the example. The final four would 
be performed on a terminal where {refno} would be a listing 
and R would be a directory-cartridge. These operation 
classes are quite general, and later sections will narrow 
their scope to certain well defined procedures. 

But now, how can we justify this rather complex struc- 
turing of the system in terms of our goals? Let us consider 


the goals one by one: 


lL. User Perspective 
The concept of data-types, or headers, identify 
each reference number as being associated with a 


given type of data. Hence, the user thinks of 
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his data in terms of their type, or header, 
rather than in terms of its PL/1 representation. 
This is exemplified by the fact that no matter 
how data is stored on a console cartridge, the 
user can handle it merely by pressing the button 
corresponding to the cartridge name; i.e., the 
machine handles representational considerations, 
and the user is free to imagine all his different 


kinds of data in terms of their type name. 


Modularity 

The freedom to use virtually any organization of 
data or relations is guaranteed by this structure. 
All that is needed is an appropriate DSM or RSM 

to handle that format. The interfaces in the 
system are uniform and well defined; addition of 
new modules becomes little more than writing them. 
This fact is not easily accounted for in our model; 
we are proposing that new consoles and terminals 
are easy to add when new format cartridges are to 


be handled. 


Exportability 

Of course, the major feature of the system for 
exportability is the PL/1 language (see Chapter I). 
Beyond that, two important facts remain. First, 


the manager can be designed to incorporate all of 
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the machine dependent code, leaving the RSM's, 
DSM's and information free for transplantation 

to any machine. Second, the interfaces are so 
explicit that any additional modules needed by 

a new machine could easily be interposed in a 
calling sequence between two system modules. 
There is no analogy to the example, except if 

the entire system were adopted by another company 


with different microfilm equipment. 


Controlled Sharing 

Clearly this system allows for sharing by mere 
sharing of data areas (cartridges). The control 
arises from the fact that access to relations can 
be given selectively. For example, an employee 
might have access to both the name and salary 
cartridge (Data Areas) but by being denied access 
to the name-salary relation cartridge (relational 
data) he has no way of making the associations. 
The advantage to this scheme is that the employee 
could well be permitted to examine other relations 
containing name and salary (e.g. name-address or 
salary-contract) and still never be able to asso- 
ciate the two. On the other hand, circumstances 
might dictate that a console cartridge (or data 


areca) be denied a user, and still allow to him 


ae 
all relations involving it. For example, we 
might not care if it is known from name-classi- 
fication that ten people are of the same rank, 
but we might want to protect just what that 
rank is. In short, with all data and relational 
data stored in modular units, we need worry in 
general only about sharing these units, rather 
than about sharing parts of a larger combined 


medium. 


5. On-Line Capabilities 
This is a function of how the system's functions 
are adapted for use, and does not bear on the 


system design itself. 


As to the unstated goal of efficiency, there are a couple 
of points to consider. Appropriate design of RSM's and DSM's 
can optimize operation to conform to the most frequent func- 
tion that the module must perform. For example, an RSM can 
be designed to optimize inversion, just as one can be de- 
Signed to optimize retrieval operations of a uni-directional 
nature (i.e., with name-address-telephone, we are always 
given a name and asked for the other two, but rarely in any 
other order). Also, we achieve some saving of space by 
using reference number tokens in relations; duplication costs 
only the length of a refno, not of the data itself. 


That summarizes the structures and motivations of the 
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GOLD STAR system. In the next chapter, we will consider the 
set theory upon which these structures are founded, and how 
set theory leads in logical progression to the concept of a 
quart. 

Chapter IV will discuss the implementation of GOLD STAR 
and provide an insight into some of its current design capa- 
bilities. Chapter V will present the user interface, i.e., 
the functional calls to the manager of the system. That 
section also discusses the programming considerations of 
note, as well as presenting an example of the use of GOLD 


STAR. 


eee 
CHAPTER ITI 


SET THEORY OF GOLD STAR 


1. The Rhetoric of Sets 
Each individual perceives the "relatedness" of two 
items of data based upon his particular perceptions and 
biases. Visual proximity, concurrent sensations of taste 
and smell, or remembered patterns of association are but a 
few means by which the human mind establishes relatedness 
of two items of information. Different individuals often 
interpret the same collection of information in vastly 
different terms of relatedness; the string 'V-8'' as con- 
strued by the auto enthusiast signifies something afar from 
the meaning assumed by the connoisseur of vegetable juices. 
At the core of GOLD STAR rests the firm belief that 
data relatedness is best conceptualized apart from the com- 
putational processes which implement relatedness. One con- 
ceptualization method, set theory, permits this separation, 
and offers several unexpected benefits: 
-- Set theory is sufficiently general to encompass 
the operations and associations normally subsumed 
in the term "data management". 
-- As an outgrowth of pure mathematics, set theory 
offers unambiguous, albeit complex, semantics; 
furthermore, set operations and their limitations 


are well established. 


-35- 

-- The subdivision of a system into independent 
functional modules is facilitated by a set- 
theoretic framework. Set-theoretic operations 
specify quite well the tasks that any single 
system module must perform. 

The remainder of this section discusses data-bases and 
operations upon them in terms of basic set theory. The 
following section treats data-bases in light of orderings 
upon their members. 

Data-Bases 

The notations and intuitive notions used in this sec- 
tion conform with common usage Has an abstract model of 
reality, a data-base depends upon certain concepts involving 
sets, most importantly: 

The set {a,b} is a collection of the objects "a" 
and "b'' with neither ordering nor structure 
presumed among them. The elements "a" and "b" 
may be either atomic, i.e. not sets, or they 
May themselves name sets. Thus an element of 
a set can be another set. 

The ordered pair <a,b> is the set {f{at,{a,b}}, and 
indicates in the following directed graph that 
the correct sequence of endpoints is "a" followed 
by bs 


a——_—_——->b <a,b> 
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hie tuple (Caub). os the Sety ikl as <2 be. that. 1s 
a function from {1,2} to ta,b}. Likewise, the 


tuple (DN) 5N5,Nz,- 


7+ +ns) is a function from the 
Set yoyo sta eal et EO {n),M5,---n;}. 
We define a data-base B as a tuple of order three: 
B=(D,T,R) (3-25) 
The set D contains data element names, and contains 


Within its power set three particularly useful sets. 


D=NpyUN DUN, (orw) 


The members of Nj are raw data elements, that is 


elements apart from their relation to other elements. 
Por exatipbe. the elements: “Ionn reds. ose: and 
".24+3,.8351v’-] " could all be members of Np: 

The members of Nays 


among its members, are the motivation for the struc- 


and particularly associations 


ture of the Gata base Bb. “Of £1yst concern in this 
Structure is the function T, the data type function. 
T takes as its domain a set of data type names, Nop 5 
Ni =D, and maps it into various subsets of D. More 
rigorously: 

T=N, GD) (3-3) 


brom-the oxampleof Chapter IT, 


Np=iname","address","telephone"} 
T(name)=i"Abernathy, Fred",'"Barnes, John", etc. } 


TCaddressj2{ "22 Maple Ste", "535- Main. St.) ete.) 
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T (telephone) ={''783- 3055" "724-3718", etc. } 
T(data types)={"name","address","'telephone" J=N,, 


The last line is significant in that T (Ny) = 


T(data types) = N Note that this does not violate the 


T" 
axiom of regularity (x a set + x ¢ x). Ne is merely its 
own image under the function T; hence Ne e dom T and 
Np € ran T, but Ny ¢ Nov 

T is a function, but since D is finite, the range of 
T cannot be the entirety of @ (Dd), i.e. T is not an onto 
function. Furthermore, T is generally not one-to-one. Apart 
from constraints of cardinality, the first condition will 
usually hold because not all members of GD) form coherent 
data types in the eyes of the user. The lack of a one-to-one 
condition results whenever two data type names (or more) 
have the same image under T. For example, the set 

S = {Babe Ruth, Bill Dickey, Tony Lazerri, 
Lou Gehrig} 

might be T(Murder's Row) or T(Old Yankee Sluggers). Note, 
however, that T(name, ) = T (name, ) does not imply that 


name, = name,, as in the above example. 


1 
The final element of structure within B is the mapping 


from N a set of relation names and the set of relations 


R? 
existing among members of Np: Before examining the formal 
definition of this mapping, we define the cartesian product 


(or cross product) over various members of the function T. 
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Let Js Nos then the cartesian product of T over I is 


defined as 


x T(i)={f]f:I-D & (wi) (icI>£(i) © T(i))} 
iel (3-4) 


Thus the cartesian product is a set of functions, each of 
which is a set of ordered pairs; the following example 


illustrates: 
I={age,hair,eyes} <¢ Neo 
T(age)={10,20} 
T(hair)={brown,blond} 


T(eyes)={blue,hazel} 


X T(i)={{<age,10>,<hair,brown>,<eyes,blue>}, 

ve {<age,10>,<hair,brown>,<eyes,hazel>}, 
{<age,10>,<hair,blond>,<eyes,blue>}, 
{<age,10>,<hair,blond>,<eyes,hazel>}, 
{<age,20>,<hair,brown>,<eyes,blue>}, 
{<age,20>,<hair,brown>,<eyes,hazel>}, 


{<age,20>,<hair,blond>,<eyes,blue>}, 


{<age,20>,<hair,blond>,<eyes ,hazel>}} 
If |S] denotes the number of elements in the set S, then 


x TC) 


= TI 
icl I 


lel 


T(i) 


A relation is defined as a subset of some cartesian 


product of T over a subset of N The function R maps Np 


T° 


“BG 


into the set of all possible relations among members of the 
data-base. Rigorously, 
= VU. x j 
a Ney PGT GI) 
(3-5) 
Specifically, if xeNp, and R(x) is a relation over the 


cross product of T over some set I, le Nos 


R(x)a X T(i) 
iel (3-6) 


Note that the set I may have several relations associated 
with the cross product in (3-6). For example, several 


different relations could be drawn from 


XT(i) 
ie{name,address,telephone} 


yet all would be subsets of the same cartesian product. 
This implies that the exact contents of any relation cannot 
be established from knowledge only of the data type names 
involved. 

The model B defined constitutes one of many possible 
models. However, the choice of any one modei depends upon 
how well it represents reality, and more importantly, how 
well its behavior can be made to conform to the behavior of 
the situation it represents. From our data base, we wish 
to selectively retrieve certain pieces of information; hence, 
we require a set of operations which allow maximum control 
over model behavior. In addition to the cartesian product 


operation in (3-4) five other operations on members of R 


«Ags 
will prove useful. 


Let x,y € N, and 


R 
R(x) = X T(i) I=dom R(x) I = Ny 
iel 
R(y) = X T(j) J=dom R(y) JeNe 
jeJ 


Note that I=domUR(x) and J=domUR(y) are the data type names 


which participate in R(x) and R(y) respectively. The oper- 


ations 
R(x) U R(y) union 
R(x) Ry) intersection (3-7) 
R(x) - Ry) set theoretic difference 


are all defined if and only if I=J. Just as it makes no 
sense to add chickens to apples, the value of unioning a 
phone-book and a cook-book is moot within B. As with car- 
tesian product, union and intersection are commutative and 
associative; set theoretic difference is neither. 


Given a relation R (phone-book) 


x. T(t) 


R(phone-book) = ie{name, address,telephone} 


we may wish to retrieve only a portion of the stored infor- 
mation. To isolate a particular set S of name-address-phone 
elements, we need specify only those elements of R also in 
S. However, if we wish to restrict a relation via data 


types, we define a projection on R(x). Let X=domUR(x) and 


a4} 5 
let Y = Nr be the projection set. Then TyR (x) is the pro- 
jection of R(x) on those data types contained in XfY. 


Formally, 


TYR(xJ= {£2 XNYANy | (Gg) (geR(x) & feg)} 
(3-8) 


For example T (name, telephone }* (Phone book) would yield a 
relation containing all names with associated phone numbers; 
each name-phone number pair in the projection is a subset 
of at least one name-address-telephone number tuple in 
R(phone book). If |domain UR(x)]=n, then there are hig 
distinct projections. Thus for R(phone book), the projec- 
tion sets {}, {name}, {name,address}, {name,telephone}, 
{name,address,telephone}, {telephone}, {address}, and 
{address,telephone} yield 2°28 possible projections. Since 
f operates only on XNY, members of Y not contained in X 
have no effect on the projection process. Thus while a 
subset operation on R(x) yields a particular set of func- 
tions on domU R(x), the projection operation takes from all 
functions in R(x) those ordered pairs whose left component 
is contained in the projection set Y. 

Our sixth and final set-theoretic operation, that of 
relation composition, is the most powerful and the most 
difficult to define. Composition in GOLD STAR has two sim- 
ilar forms: composition in its simple form and composition 
under the auspices of a data type renaming transformation. 


Assume the existence of two relations--a phone-book relation 
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and a name-salary relation; from these we wish to assemble 
a third relation indicating salaries at various addresses. 
Our algorithm follows: 
1. We note that R(phone book) = T(name) x T(address) 
x T(telephone) and R(name-salary) =T(name) x 
T(salary); each relation involves T(name) in the 
cartesian product of which each is a subset. 
2. We take from each relation a member in which the 
names match and proceed to form a new relation 
in which members are subsets of T(name) x T(address) 
x T(telephone) x T(taxes). 
3. The new relation will contain that subset of the 
4-ary cross product above formed by following the 
rule in (2.). 
Let X=types(R(x))=domUR(x), Y=types(R(y))=domUR(y), then 


the composition R(x)°R(y) is defined as 
R(x) °R(y)={g:XUYoN, | 2£R(x) Ry) 
((Wt)(t dom g + 
(t dom f+g(t)=f(t)) & 
(t_dom h>g(t)=h(t)))} (3-9) 


Alternatively, each g=fUh. The simple composition operation 
composes on all those data type names which are found in 
both R(x) and R(y), and produces a new relation whose order 


is greater than or equal to the orders of the operand rela- 
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tions. Specifically if order (R(x))=|domUR(x)| and order 
(R(y))=|domUR(y)], then new_order=order (R(x)) + order 
(R(y))-|Xfy]. 

A capability missing within simple composition is the 
ability to match data type names which are different, yet 
have intersecting images under T. For example, if R(regis- 
tration) <= T(student) x T(subject) and R(phone book)= 
T(name) x T(address) x T(telephone), the R(registration) ° 
R(phone book)={}=¢. Such a composition may be necessary if 
an instructor wishes to call all his students in a particu- 
lar subject. To allow for this renaming, we define two 


functions X and p which apply to R(x) and R(y) respectively: 
A: XN, ,X=types (R(x) )=domUR(x) (3-10) 


p :Y>N »Y=types (R(y) )=domUR(y) (3-11) 


T 
X and p rename certain data types as specified by a user of 
the system. In the registration example, A(student)="name" 
would yield a result = T(name) x T(address) x T(telephone) 

x T(subject); the dual result, (name)=student, would yield 

a result =T(student) x T(address) x T(telephone) x T(subject). 
In both cases the information would be the same, differing 
only in the perception of involved individuals as "names" 


or "'students''. Formally, we define extended composition as 
R(X) (4° 5) RO) = {g: (randUranp) +Nq | af R(x) dh R(y) 


((Wt) (tedom g> 


iis 
((¥u) (uedomf § A(u)=t>f(u)=g(t) §& 


((Wv) (vedomh § ¢(v)=t+h(v)=g(t))))} 
(32423 
In a set theoretic data management system, the most power- 
ful operation is composition, and as one would expect, is 
also the most complex to specify. Nonetheless, it is com- 
position, simple and extended, which allows selective 
merging by data types of relations. 
Reconstructability 
The decision of what data types are to be involved in 
any relation is a non-trivial matter. In particular rela- 
tions defined by (3-5) and (3-6) may be more "complex" than 
necessary. Assume for example, that a company records for 
each employce only his name, age, height, weight, employee 
number, salary, and years with the company. The relation 


R(employee) might then contain the member 


{<weight,243>,<age,36>,<height,5'9">,<name,J. Smith>, 


<salary,$22,000>,<years employed,9>,<man #,6532>}. 


While all this data: pertains to “J. smith", certain other 
elements may have no particular bearing on each other; it 
is not clear, for cxample, whether a $22,000 dollar salary 
LS SLENITICINE VIs-deVvis. The neipnt’-5*9": However, the 
unique name J. Smith and the age "36" tell a certain fact 


about J. Smith. The projections 7 R(phone book) 


(name address) 
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I (name ,age} ® (Phone book), et cetera, have been composed with 
each other without giving us additional significance among 
the facts about J. Smith, except that such facts each be- 
long with him; but this is known already if the functions 
(name,age),etc. are within our purview. 
If we consider an office directory, however, the abil- 


ity to obtain the original relation by composition of its 


projections may be absent. Let R(phone book)= 


{{<name,Al>,<room,A-5>,<extn,317>}, 
{<name,Al>,<room,A-5>,<extn,318>}, 
{<name, Andy>,<room,A-5>,<extn,318>}, 


{<name , Andy>,<room,B-2>,<extn,442>}} (3-13) 


No set of projections (save the trivial case Thame Sebi ext ® 
can be composed to exactly reconstruct (3-13); spurious 


members would be coded. 


Given 7 mf (phone book)={{<name,Al>,<room,A-5>}, 


{name , roo 
{<name,Andy>,<room,A-5>}, 


{<name,Andy> <room,B-2>}} 


and TH R(phone book)={{<name,Al>,<extn,317 >}, 


ame ,extn} 
{<name,Al>,<extn,318>}, 
{<name,Andy>,<extn,318>}, 


{<name ,Andy>,<extn,442>}} 


then composition would generate the spurious members 


{<name,Andy>,<room,A-5>,<extn,442>}, and {<name,Andy>, 
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<room,B-2>,<extn,318>}. In fact, no set of projections on 
(3-13), when composed, yields R(phone book). The ensuing 
theorem provides a condition sufficient for relation recon- 
struction. The phone book example in (3-13) is not recon- 
structable from any set of its projections because we can 
find no single projection which would uniquely "tie together’ 
the information stored there. In the employee relation, 
there exists, among others, a binary function which maps 
every name to an age, i.e. there is a function from names 
to ages. This fact assures us that, given a projection 
containing a name, weight, etc., the composition of the 
name-age function and this projection will yield a member 
of the relation R(employee). The existence of such a func- 
tion f gives rise to a definition of relation reconstructa- 
bility: 

Definition: Let P={myR(x) | Ys domuR(x)}, i.e. the set 
of all projections on R(x). R(x) is reconstructable 
if and only if 

3P' s P such that 


pep’ =R(x). (3-15) 


With this definition in mind, we now state and prove 
a theorem sufficient (unfortunately not necessary!) for 
reconstructability: 


Theorem. 


Le {S1,S,,S,} is a partition of dom R(x) and 


ws 


+ W! + tt + 7 
Msaisay is a "function", that is, if 


VT), Aitz(((t,€8 s,s? & Ose esa) 
& ( ) R(x) ) 
ToUT 2 ©T(SUS5) x 


(3-16) 


then R(x) is reconstructable, and 


R(x) R(x) R(x) 


~ ™(S\US,) "(S2US3) (3-17) 


Proof: 


If Lemma I of Appendix A is applied, then in (3-16) 


R = R 
iss"Suss) > since) 
or 
To TW R(x) = tT. R(x) (3-18) 
S5 (S,US,) S, 
and 
Ree Wee ee. eR R(x) (3-19) 
$,°(S,US,) °°" "Ss 


Thus the function (3-16) can be simplified to 


Wt, atts ((t, € i G (t, € ise & 


(T,U Ts € ™(s,US_) 8(4))) (3-20) 


We now show that 1) any member of the left side of 
(3-17) is also a member of the simple composition on 
the right, and 2) that conversely, any member of the 


composition is also a member of R(x). These two 
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steps constitute the proof of (3-17). 


I. 


II. 


Let g e€ R(x). The definition of projection (3-8) 


assures the existence of some fy € Msg 8) 


and some f, € "($US R(x) such that fy = g and 


3) 


£, eg... That: ais 


(3 f,.f,<s)(f, € MSossje 6 & f, € Mega." 6) 


Since dom fy = S,US, and dom f, = S,US, 


> 


dom f, U dom f, = dom g = SjUS,US z = dom UR(x). 


fy and f, 


domains equals the domain of g, f,Uf, = g. The 


are functions; since the union of their 


union of f, and f however, is equivalent to the 


1 vias 
binary composition of f, and f,, since 


(vt ce dom g)(t ce dom fy & t e« dom f, > 
£,(t) = £,(t)) 
Thus the element f,°f, = g for some g € R(x). 


Let f, € "Gus, ° and f, E "(SUS R(x), 


3) 
such that 
f° Fs, eo tr RO) at R(x)). 
| ae? (S,US,) (SUS ,) 


fy is g restricted to SUS, for some g e€ R(x). 


Consider an f,' which is g' restricted to SUS, 
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; P : 
for some g' e€ R(x). Since Nie is a 


"function" in the sense of (3-16), f, restricted 


to S, = f,' restricted to Sos so g = g'. Hence, 


for all fy € 7 R(x) and for all f 


€ 
(S,US,) 2 


T(u5,) RU): there exists a g € R(x) such that 


fy f, = £,°f, = g. Thus all elements of the 


composition of (3-17) are also members of R(x). 


QUE. D3 


Knowledge that a relation is reconstructable can aid 
in retrieval operations on the data-base B. Given the 
relation 

R(phone book) = X T(i) 
i e {name,address,telephone} 
and the necessity of telephoning someone named "John", 
then the operation 


Tonner R(phone book) ° {{<name,John>}}) 


will yield a unique phone number if John has only one 
phone. The above operation for any person would yield 

a unique phone number if there were a "function" in the 
sense of (3-16) from names to phone numbers. Note however, 
that if John has two phones then the above operation will 


yield a set of two elements. 
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Even if we have no function from names to telephone 
numbers, this does not imply that retrieval of a unique 
phone number is impossible. For example, if every pair 
of names and addresses is "mapped into'' a unique phone 
number by the "function" of (3-16), then by specifying 
both John and the additional information that he is cur- 
rently at 10 Main Street, we can retrieve his unique phone 
number. The operation 


Toone R(phone book) ° 


{{<name,John>,<address,10 Main Street>}}) 
will yield the unique phone number if the above condition 


holds. 


2. Ordered Set Theory 

In considering how we might implement a relation, we 
must come to terms with the most pervasive real-world 
consideration to which we are bound, namely order. Order 
is imposed in almost all environments; symbols anda 
notation will be written in a linear order, anda 
representation of a set is free of order only by intention. 
Most extant computers employ a sequential numerical ordering 
scheme, the most common of orders. Hence, we must conform 
to this constraint of order and include this notion somehow 


within our framework of set-theoretic concepts. 


Ser 


An ordering 2 is a bijection (one-to-one, onto 
Mapping) from an index set I to a set S, each set 
containing k elements. The index set I contains 


the successor of all but one of its elements. 
Q:1 S where S3je1|j*¢1 § Vit}, iel iver (3222) 


Paraphrased, ® assures us that we can step in some 
well defined sequence over the index set (via successors). 
Elements of S are thus associated with an ordering 
procedure. 

With <a,b> defined as {{a},{a,b}}, we define a special 
case of ordering, the tuple. We already have an intuitive 
feel for a tuple, e.g. (a,b,c). We recognize that the 
physical position of an element is as much a piece of 
necessary information as is the element itself. The tuple 
(b,b) can exist, for example, while the set {b,b} cannot. 


But a tuple can be viewed as follows: 


A tuple t is an ordering Qe where the index set Ip 
has the special properties that it is a subset of 
the natural numbers and contains the element 1 if 
non-empty. Formally 


T:2,:1,,7%5 where I ©N, diel +Lel 


fleas zi £ £ 


+ ae tes hee .+ 
k tl, § Vik, ieI pri el, (3-22) 


dkel,| 
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That is, a tuple is the special ordering from {1,2,3,...,n} 
to the n elements of the range set. In set notation, a 
tuple is represented as 


(t,t, — »ti) = {<1,t,)>,<2,t,>, ide »<n,t >} 


A tuple is readily represented on a real computer, 
since the order of a tuple coincides with the most prac- 
tical implementations of order. However, an arbitrary 
ordering 2 may not be easily representable; therefore, at 
some point, if no other assumptions are made, we must use 
tuples (or whatever real-world form of ordering to which 
we are bound). 

As an alternative to a given environmental ordering 


we define an entity called an explicit element. 


An Explicit Element e is an element which is 1) 
meaningful in a global sense, and 2) recognizable 
independently of the context in which it is found. 


ale 2 appeared only 


For instance, if the word "fremitus 
once on this page, we could locate it unambiguously, 
independent of the way in which the words on the page are 
scarched. We can also determine its meaning free of the 


context of this page. Note that any element can become 


explicit by merely restricting the context of consideration 
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sufficiently; if we search only one word it must be explicit 
since no duplication exists as long as the word is 
meaningful. The requirement of global meaning is significant 
in computers, since many words are not meaningful to a 

given search request (e.g. the octal word 777777 has no 
meaning when viewed as four ASCII characters.) 

Often we wish to make the elements of Ne and Np (see 
section 1. of this chapter) explicit elements. It is 
desirable that these names be recognized in a context-free 
sense whenever they appear. Consider the set E of explicit 
elements where ecE > eeN... With E we define another entity 


which will be reencountered later in the discussion. 


An Explicit Naming Tuple is a tuple whose range 
consists entirely of elements e, where e€N, and 
e 1s an explicit element. 


ENT: Qe? Te ca {e),€9, eee ,e,) e.eN,,eeE (3-23) 


In cffect, an ENT defines an arbitrary order on the ele- 
ments of E which will prove useful. Since ENT is a 
function, its range is totally ordered. 

The ENT function is intimately tied to the definition 
of a relation. A relation R(x) assumes the form 


R(x) = {{<e,,d)1>,<€ysd54>5 bas ,<e,,d5>t, 


“he 


{<e,,d,>5<@y5d5975 ,<e do>t, 
Ese pidig? Sepoeaa? pene tages 
{<e,,d)>,<e,,d,,>, bs »<e, od th (3-24) 


Since R(x) is a set, the subscripts identify, but do 


not order the particular elements involved. Note that 

dom UR(x) = {e,,€55 aude ,e,} (3-25) 
Consider the class of functions 

ENT: {il[l<i<n}+(1 to 1, onto) domUR(x) (3-26) 
There are n! possible ENT functions for any R(x); each such 


ENT will be denoted by a subscript. We take in particular 


some ENT, such that 


k 
{<l,e 


ENT, (R(x) ) >,<2,€5>, «ee »<n,e,>] 


1. 
(e189, Sods »€,) (3-27) 

The subscript k serves only as an identifier for the 
particular ENT chosen. An equally valid choice might be 

ENT) 1 (ROX) )=(e, 5,4 08,2 Sales »€5 50) (3-28) 
ENT, (R(x)) and ENT)» (R(x) ) are distinct bijections on the 
same relation. Each ENT function is an arbitrary ordering 
of the data type names in dom UR(x). The particular order 
is specified by which of the n! possible orderings is 


chosen. 
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As defined in (3-27), an ENT is a function with respect 
to a relation. The particular k chosen depends on the organi- 
zation of R(x) desired. This indicates how the ENT empiri- 
cally defined in (3-24) is chosen. The explicit nature of 


the elements of domUR(x) is, of course, maintained. 


At this point, we introduce some additional functions 
which transform R(x) into another entity. The transformations 
will also exhibit the following characteristics of the rela- 


tion R(x). 


1. Given a data element d Ny» we can determine a type 
with which it is associated. This is possible 
Since each member of a relation R(x) is itself a 
bijection: 

t: erd | teR(x) & (Wi,jsn) dom t,=dom t, (3-29) 


tly in turn, maps d onto e. Note that since t 


is a bijection, we are always a unique e given 


a specific d. 


ty 


Given an e and an R(X) we can determine all instan- 
ces of d (i.e. the exact subset of Ny) which corres- 
pond to that e. These are merely the mappings t 


over all of R. 


Every element of R(x), by virtue of the fact that 


tA 
* 
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R(x) is itself a set, indicates a relatedness 
among its members. That is, 
row: x "is related to" y where x,yeran t, 
t e« R(x) (3-30) 
4, Every member of R(x) includes an ordered pair 
for every e. The d's in these pairs are also 
related by virtue of their association with 
the same type e. 
column: x "is related to" y where x=t;(k), 
y=t, (k) for all i,j<m and for 
all k<n (3-31) 
The nature of relatedness expressed in characteristics 
three and four is at this point intuitive, but will 
become clearer as transformations are performed upon 
members of R. The names “row'' and "column" are used to 
indicate that when notation such as in (3-24) is used, 
relatedness exists by virtue of the physical structure 
of rows and columns. 
We define a function called Tuple with Explicit Naming 
Tuple (TENT): 
TENT: tot! | teR(x)5.t! = t ° ENT (3-32) 
More specifically, consider a given ENT, R(x). Then 
TENT, (t) = t ° ENT, (R(x) ) | teR(x) (3-33) 
Note that both the domain and range of TENT, are functions. 


The domain is a function from e to d; the range is a tuple. 


257% 


Using the notation for R(x) in (3-24), we can formally 


express a typical TENT: 


ENT =(€,,€5, +--+ -€,) [k arbitrary] (3-34) 


= ° 
TENT, (t,)={<e,.4,]>> Sak »<e 5d 1>} 


{<l,e,>, ee »<n,e >} 
={<1,d,,>, fas »<n,d_>} 


=(d d 


71? 21? (3-35) 


We note that the elements of the TENT are ordered in a 
fashion analagous to that of the particular ENT, . aK? 

from (3-28) were used instead, the TENT would appear as: 
(3-36) 


TENT, , (t,)=(d, 54 id 


ney 4? 21°444) 
It should be clear that each of the TENT's (with 
respect to 2 given relation R(x)) will each be ordered 


with respect to the ENT, chosen to order the given R(x), 


k 
since 
l<i,j<m dom t,=dom tj ran ENT (3-37) 
In gencral then, for the R(x) of (3-24) the jth TENT: 
TENT, (t,)=(d); 54; .42;, re dis) 
TENT Ct)" Wage dn ig gedy a ge: oes dg gy) C728) 


and so on for any choice of ENT. 
Note that we preserve the same content between 


a TENT, (t; ) and its ENT, as with the element t; of R(x) 


k 
itself. This follows since all derivations are bijectional, 


Ae 


and it is possible to "go back''. Thus we seek a structure 
which will include all TENT) 's and the ENT, . This structure 
would then contain all the information found in the relation 
R(x) itself. 


Therefore we define a sort on the various TENT's 


SORT (R(x)):{j|1<j<m}+(1-to-1, onto) 
{TENT (t) |teR(x) } (3-39) 
There are m! possible ways of ordering the m TENT's derived 
from R(x). SORT is esentially a second arbitrary order 
placed upon the relation. However, there are a few standard 
SORT mappings which are used more frequently than others. 
The one used in GOLD STAR is called a lexicographic sort. 
We define lex ordering of TENT's as follows: 
TENT, (t,.) (lex less than) TENT, (t,) iff 
Gi) (1sisn & (Vj) (J<i+ TENT, (t,) 3) = 
TENT, (t)()) & 
TENT, (t,.) (4) <" TENT, (t,) (4) (3-40) 
where 
TENT, (t .) (p)= the pth element of the 
aia TENT 
Note that the = operation is determined by the ENT) chosen 


in the sense that the jth element of the TENT is determined 


by the orderings ENT, . For example, 
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Let 
TENT (1)=(1,2,1,3) 
TENT (2)=(1,1,1,1) 


TENT (3)=(2,1, 3,3) 


aca (3-41) 
be determined a relation 

SORT, .,,(the TENT's)= (TENT(2), TENT(1), 
TENT(4), TENT(3)) 


For example, then, 


TENT(4)A TENT(3) since for i=4, j=1,2,3 


th 
t 


TENT (4) (1) = = TENT (3) (1) 

TENT (4) (2) = 1 = TENT(3) (2) 

TENT(4) (3) = 3 = TENT(3) (3) 

TENT(4) (4) = 2 < 3 = TENT(3) (4) 
Lex ordering, then, is the intuitive order where the first 
component of the TENT's is most significant, the second is 
next most significant, etc. The importance of ENT, is in 
the determination of which is the first component, which is 
the second, and so on. 

We now define what appears as a trivial construction, 
the QUART: 
QUART = CENT, (R(x)), SORT (R(x) )) (3-42) 
(QUAsi RelaTion) 


For a typical relation R(x) as defined in (3-24), 
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QUART (R(x)) = 

(Ce, .e,, ee ss »€,),(d,,,45), eo) 3848 di); 
(iid heres deals 
(di sde ie vay Gdn) (S243) 


The construct QUART has two noteworthy properties, over and 
above those possessed by R(x)) itself: 
1. Two arbitrary orders are imposed upon the 
relation, namely ENT, (R(X) ) and SORT(R(x)). 
2. The elements of ENT appear only once, 
giving a "factored" effect. This is highly 
desirable since by the definition of 
explicit elements, we can now consider a 
QUART as a context of consideration. (See 
3-23). The relation in its proper form 
has redundant occurances of the explicit 
elements, which limits our context. When 
transformed to a QUART, we can unambiguously 
identify the e's, and hence ease the search 
for information. 
Note that QUART(R(x)) retains all the information found in 
R(x) and discussed previously. By following the various 
bijections created in the derivations we can freely translate 


one form of information to another, e.g. 
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1. Given a d, find an e, e,= ENT, (TENT, (3) (45) 
2. Given an e, find the d's associated with it 
a" = {TENT, (3) (ENT, *) over all j's} 
3. Each TENT relates all d's with it. 
4. The d's defined above relate all d's of a 
given data type. 
The notation used in (3-43) lends itself to an even 


clearer form: 


he ee as (3-44) 
diy 4] da 
diz doo diz 
din don di 


This form is already familiar from (2-1) and (2-2-d). As 
expected this form represents a relation. 

Henceforth, where a QUART is mentioned, it will be 
assumed that it is in effect a relation. We refer to its 
structure as follows: 

CENT, or PENT: Two computer representations for 
the types, or e's in our formulation. 
(CENT is Character ENT). 
(PENT is Pointer ENT). 

Order: The number of elements in the ENT and each 


TENT (= |dom UR(x) |= n). 
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Length: the number of TENT's in the QUART, which 


was m in our formulation. 


When we mention the term ''relation" henceforth, we mean a 
relation stored in some form other than a QUART. This section 
has discussed how any representation of a relation (which 
represents the abstract notion of a relation in (3-24) 

can be transformed into a QUART. Other relational organiza- 
tions are considered in the next chapter. 

One final concept remains: that of a successor in the 
context of a QUART. We have adopted the view that the successor 
of a TENT is the next TENT according to the SORT function 
adopted. This follows either the specified TENT, if it is 
part of the QUART, or follows the place where the TENT would 
have been inserted if not already included. More succinctly, 
the successor operation is a least Upper bound operation. 


For example, given 


a bic 

1 1 1 

1 3 1 

1 3 3 

Z 1 2 
successor[{(1,3,1)]}] = (1,3,3) 
successor (C152 51).)) = -(ls5,1) 


Further examples of QUART operations are found in 


Rive Gardy eye dey ck 
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CHAPTER IV 
AN IMPLEMENTATION OF GOLD STAR 


This chapter discusses the rationale for one GOLD STAR 
implementation. The system is not of the direct transplant 
variety, since we have chosen to utilize some features 
peculiar to the present target computer -- the GE/645/MULTICS. 
Furthermore, the algorithms mechanized for the MULTICS sys- 
tem may be less suited to environments other than ours. 
Despite certain shortcomings, we feel it advantageous to 


pursue the cogs and machinery of GOLD STAR/MULTICS. 


1. DSM Modules 
Representation of Data Elements 

Every computer system faces the problem of dual repre- 
sentation of data elements: one representation allowing fast 
internal operation of the programs, and another suitable for 
human consumption via printed or graphic input/output oper- 
ations. Classically, i.e. in "algorithmic" languages, the 
formats for user data have been dictated by "representation 
types" such as integer, floating point, logical, and fixed 
point data found in FORTRAN systems. In GOLD STAR the term 
“data type" refers to classification of data according to 
some attribute assigned by the user (e.g. "cities", "last 
name''), and not according to some internal code peculiar to 
the computer environment. To the user, this distinction 


between "representation type" and "data type" is significant: 
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in the former case, environment idiosyncrasies force extra 
meaning on the data due to representation, while in the 
latter case all semantics depend upon the user's own cClass- 
ification of the data. 

While the user views his data elements only in terms 
of datu type, there still remains the issue of efficient 
internal representation. Although relatively transparent 
to the user, the techniques utilized to increase the speed 
Cf Operation. merit further sScrutray. dinternally,.-all ser 
data iS manipulated in the form of word-length bit string 
tokens, which we refer to as reference numbers. The task 
of binding strings to reference numbers is performed by a 
class of GOLD STAR sub-programs called data strategy modules, 


or DSM's. 


The Binding of Reference Numbers to Strings 
At the time a user creates a new data type within GOLD 
STAR, he usually perceives or assumes a total ordering on 


the elements of a data type. The method of assigning refer- 


ence numbers to strings begins with the requirement that 


rhe total ordering on members of any data type ts 
completely preserved by (t.e. tsomorphte to) the 


total ordering on the asstgned reference numbers. 


a 


we turther require that valid comparisons between data items 
exist only if the comparands are numbers of the same data 


type. 
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Binding of Reference Number Via Alphabetic Order 

The module dsm_astring binds strings to reference 
numbers in such a way that ascending reference numbers 
preserve alphabetic order among the data elements. The 
notion of alphabetic order is deeply ingrained in most 


individuals, and is significant in that it is a common 


ordering scheme applicable to arbitrarily large lists of 
strings of any length(s). Universal usage of alphabetic 


order requires a facility, i.e. dsm_astring, for its accom- 
odation; dsm _astring serves this purpose. 

For each data type it manages, dsm_astring maintains 
a binary tree in which data elements are stored and from 
which they are retrieved. Because collating sequences in 
ASCII and otner codes preserve alphabetic order, dsm_astring 
is able to compute order-preserving reference numbers direct- 
ly from the input character strings. The exact method by 
which this operation works will become clearer if we follow 
the procedure invoked to perform a binding operation on the 
data type "names". (By binding we mean inserting a new item 
into a DD area and associating an appropriate reference 
number. ) 

The user creates the data type "names" via a call to 
mger$new_data_type and initializes the header shown in 
Figure 4-1. (Hach data type is stored in a separate segment 


in the MULTICS system, and its size is controlled via the 
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"allocate" and "free" statements in the PL/1 language.) 

The header contains information required by GOLD STAR for 
system calls, as well as pointers to the tree root, the 

head of a successor chain, and counters uséd to indicate the 
number of free and empty cells. The user establishes to 
GOLD STAR that the DD area "names'' will be managed by dsm_ 
astring; he does so by specifying the DSM name in the call 
to new_data type. Subsequent references to ''names" will 
automatically invoke this DSM. 

Figure 4-2 illustrates the logical changes in "names" 
resulting from the insertion of "Ezra". Two actions occur: 
the root pointer is set to the address of "Ezra", and the 
canonical root reference number is assigned. The root 
reference number is defined as 


_ »h-2 
ref oot 


where n = the number of bits in a full word. The choice 
of this quantity as the root reference number implies there 
are as many positive reference numbers greater then ref oot 


as there are less than ref and facilitates the forma- 


root’ 
tion and maintenance of a tree symmetrical about the root. 
In subsequent action, the successor chain head is set to 
"Ezra and the number of cells active in "name" is incre- 
mented by "1". As "Ezra" has neither descendants nor a 


successor at this point, these pointers in the data item 


are null. 


~69- 

Figures 4-3 and 4-4 illustrate the method by which 
dsm_astring computes reference numbers. In Figure 4-3 
the name "Claude" is inserted in the tree as Ezra's left 
descendant, since ''Claude" is lexicographically less than 


"Ezra". The reference number of "Ezra" (= ref } is the 


root 
only reference number at level 1 in the tree. Reference 
numbers for descendants of an item present in the tree are 
computed as follows. 

A candidate data item for insertion is compared with 
the root note item. If the candidate is less than the root 
(according to alphabetic ordering), then one of three situ- 
ations can occur. If the root item and candidate are equal, 
then the candidate is already present; search stops. If 
the root item's left descendant is non-null, then it becomes 
in effect the root, and search begins at that point. If 
the root item's left descendant is null, then a number of 
words required to store an item are allocated, pointers are 
chained and the new reference number is computed via the 
formula 


2 (d-i) 


"left descendant 7 


"parent 


where d is the maximum depth of the tree, and i is the depth 
of the tree at which the parent node appears. 

If the candidate item is alphabetically greater than 
the root item, then a procedure analagous to the above pro- 


cedure for left descendants is executed, on the right, with 
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CoS SS Se ee ee 


i a een 


Figure 4-4: Insertion of "Milton" in Data Area 
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"right descendant ~ Toarent 


Note that the reference numbers for left and right descen- 
dants will be less than and greater than, respectively, 
the reference number of the parent node as long as i < d. 
When i exceeds d, this implies that no more items may be 
inserted in the tree below the current "working node". The 
exact reasons for this limitation result from the fact that 
the level of the tree i occupies one bit position in the 
reference number, with a left turn at level i being indica- 
ted by a 0, a right turn by 1 in bit position i in the ref- 
erence number. Thus a reference number of d bits allows at 
most d levels to a binary tree. A more complete discussion 
of dsm_astring and tree-overflow is found in Appendix A. 
The module dsm_astring is ideally suited to the task 
of binding reference numbers to alphabetically ordered 
strings, since insertion and deletion of items requires no 
reshuffling of data elements. The ability to delete and 
insert items without restructuring is an important consid- 
eration, but perhaps the greatest value of the tree search 
is the fact that for a data type of n members, the average 
search time is Kkog n where the constant K is independent 


Od: “M:, 
Binding ot Reference Numbers to Integers 
Like the ordering on alphabetic strings, an ingrained 


ordering is the consecutive nature of the integers. Classi- 
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cal data management systems have recognized this important 


ordering, 


but only by providing a specific internal computer 
representation. As mentioned at the beginning of this sec- 
tion, GOLD STAR treats all data types in relation only to 

a perceived ordering. Thus a module dsm_integer maps data 
clements representing integer ordered strings into fixed 
length bit strings. (The dsm_ integer module uses the same 
internal format for integers that a classical] data manage- 
ment system would. That is, strings made up oft the charac- 
ters "O" to "9S" are transformed into internal machine binary 
representation. Thus, GOLD STAR converts character strings 
representing integer data, to binary numbers representing 
integers to the target computer. However, "integer" isnot a 
data type; data types such as "population", "number of | 
children" etc. are examples of data types utilizing the 


integer ordering on strings.) 


The Binding of Reference Numbers to Strings Where a Well- 
Ordering of String is Inapparent from the Alphabetic Order 
Two other data strategy modules complete the data 

representation repertoire of GOLD STAR. Very few data 
types of large membership ever utilize an ordering scheme 
other than the two previously mentioned, simply because 
humans find memorization of many ordering schemes incon- 
venient. However, certain data types of small membership 
size (e.g. the months, or academic titles) follow ordering 


relations mot directly disccornible from the. data elements. 
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In cases where the ordering is static (i.e. no insertions 
in the data type, as in the case of "months of the year") 
the module dsm table assigns indices in the table to data 
elements. The data type "months of the year" would map 
January in 1, February into 2, etc. For small data types 
which are of dynamic rather than static nature, (e.g. the 
collection to titles in a company) a module dsm_chain is 
provided. dsm_chain allows insertion and deletion of items 
which are maintained in order on a single threaded list. 


An inserted item assumes the reference number 


r= 5 ( Iie 


Yr a 3 
predecessor successor 


2. RSM Modules 

Every relation in GOLD STAR is stored in its own seg- 
ment, and each such segment is organized and managed by a 
program known as an RSM, or relational strategy module. An 
RSM operates on one particular physical organization of 
relations; in most instances the number of relations will 
far exceed the number of separate relation organizations. 

The choice of which RSM is the most likely candidate 
for creation and maintenance of any relation is probably 
the user's greatest single problem. He must decide which 
structure is most suited to operations involving the rela- 
tion. If the relation is large, will it require simple 
organization due to storage limitations? Will the relation 


be modified frequently? Is there more than one frequently 
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used lexicographic sort of the relation? 

Among these questions, there is a hint of the magni- 
tude of problems involved in the choice of an RSM for any 
relation. Like the DSM choice, several factors are in- 
volved, and since most CPU time will be incurred during 
RSM operations, the judicious choice of an RSM is critical. 
The more significant factors are: 

A. The number of different lexicographic sorts 

with respect to which the relation will be 
accessed. 

B. The frequency of use of the relation. 

C. The probability distribution expressing 

relative access to each item. 

D. The number of tuples in the relation. 

E. The envisioned dynamic nature of a relation. 
If insertion and deletion of relation mem- 
bers is frequent, then some RSM which chains 
items together by some ordering other than 
storage location is called for. 

IF. The basic structure of the relation itself. 

A many-to-one or one-to-many relation may 
have to be managed entirely differently 
from a nearly one-to-one relation. For 
example, a relation in which names have 


several telephone numbers is many-to-one. 
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Thus far, these guidelines have been enunciated, but 
very little is known (other than empirical testing) about 
their measurement. Our efforts this past year have pro- 
vided an RSM managing quarts, and other possible RSM struc- 
tures. We decided that all RSM's, in addition to normal 
operation entries, should contain entry points for convert- 
ing between a quart and the particular relation structure 
managed, and vice versa. This allows a user to consider 
several alternative RSM's and test the operation of each; 
the user enters his relation once, and can then proceed 
among the desired RSM's via subsequent calls to convert_to_ 
quart and convert_to_ relation. Morever, this double struc- 
ture format involves only a small amount of code compared 
to most operations. 

The following constitute the RSM repertoire in the 
initial version of GOLD STAR. 

A. RSM _Q -- assumes operands are quarts, but 

treats them as non-transient members of the 
function R. 
B. RSM_WQ -- assumes operands are quarts, but 
does not provide for keeping these quarts 
beyond the life of a process. (See next section). 

C. RSM _TREE (under consideration) 

While both RSM Q and RSM_WQ manage extremely simple 
relation organizations (which are lexicographically ordered 


matrices with some trimmings) they offer the least power of 
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all RSM's. Sorting, dynamic insertion, and dynamic dele- 
tion all require creation of new quarts which hold the 
modified relation. In cases where large relations are 
involved, these operations, or other RSM operations re- 
quiring these services as subfunctions (composition, union, 
intersection, etc.) may become extremely costly and time- 
consuming. Moreover, in on-line operations, searching for 
or modifying even a single tuple in large relations may 
disallow quick real-time response. For certain relations, 
it may prove expeditious to use a tree structure similar 
to those of TDMS or the MacAIMS proyect 42t M.1.T. 
While these structures require more space to implement, 
addressing an item depends not upon restructuring, but 
rather upon the use, manipulation, and modification, of 


certain pointers at each node. 


The RSM_WQ 

This is the module which performs the basic system 
operations on quarts only. The reader is referred to 
Appendix [ for some examples of such operations. A few 
interesting issues have arisen in the implementation of 
the Working Quart RSM. 
A, Union, Intersection, Difference 

These operations all use fundamentally the same code 
(see Figure 4-5 for flow chart). A key issue, however, 


was whether to sort the second input with respect to the 
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first before operating, or not. To solve this dilemma, 


Let 2, = length of first quart 
om) = length of second quart 
0 = order of each quart 
S = a'"search'', or the comparing of one quart 


element with some given entity. 


We know that a simple token sort of the kind used in RSM _WQ 
takes a number of steps 


#S(sort) = 072 log2 (on the average) 


Once the quarts are both sorted alike, we can recognize a 
best case in operating. 

When the first TENT of one quart is lexicographically 
greater than the last TENT of the other, then it is possible 
to determine this by only examining the first element of 
each of those TENTS; we can then determine the union, inter- 


section or difference. For example, given 


a boc a b «€ 
1 2 3 10% 11 #12 
Ae 5S 6 13 14 #215 


since 10 is yreater than four, we know the intersection is 
cmpty, the difference is the first quart, and the union is 
the combination of all TENT's of the two. 

We can also recognize a wors case (see flow chart) 


where we must examine every element at least once during 
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the steady progression through each quart. This yields 


2 S$ #S(operate) ¢$ (25 + h 


)0 
Hence, to sort and operate, we get, as an average, 


2 


#S(sort §& operate) = (2, + 25 + 0>-2.1lag% 


1 2 2 

In assessing just how many comparisons are needed to oper- 

ate in an unsorted case, we again examine a best case: 
For each TENT in quart 1, we need only search the 
entire length of quart 2 once (2,/2 average searches) 
during which we find an equal TENT; that means that 
the first match found for each of the TENT elements 


is the only one. An example of this would be: 


quart 1: a, ee oS 2: BG Fa 
LL @ 3 Ze Oe aE 
4 3 6 10° 11 22 
7 8 9 5 6 4 


Here, if we start searching the a column in the second 
quart, we need go no further since the b and c columns 
will also (and always) match (presuming a match was 
found at all in a). This best case requires £4 (2,0) /2 
searches. 

We can also ascertain a worst case: 
For each TENT in quart 1: every column in quart 2 
must be searched (250/2 average searches) for each of 


the columns in quart 1. That is to say, when a match 
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is found in column a, one is not found in b and a 
must be searched for again, with the worst case 
being once for the entire length of a (if all of a 
is the same). This case takes £1 £50°/2 searches 
on the average. 
Let us now compare the two cases: 


Sort then operate No sort 
2 < < 2 < 
2+0°R log 4 5 #S S (£)+2,)0+0°R loge, (2,250)/2 § #S 
2 
$ (2,250 WZ 
On the average 


0*1oge 2 ,£,0°/4 


(2,+2,)0/2 +2 2 


2 
letting Lpahaah approximately 
2 
20 + 20° logs 2707/4 
dividing each by 20 


1 + Ologe 20/4 


for £=100, 0=3 


Ds Se a 75 


for £=10, 0=3 


So, for most configurations of quarts, the sort oper- 
ation is well worth the tune. That is why that course of 


operation was chosen. 
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B. Composition 
A first consideration in composition is how to specify 
it. We face a number of decisions: 
1. Compose or not on columns with equal CENT's 
2. How to indicate composition on columns with 
unequal CENT's 
3. Whether or not to keep the resulting column 
The scheme adopted of binding all CENT's involved to a user 
supplied vector of names has the following effects on the 
decisions: 
1. We compose by equality of bindings, not CENT's. 
This allows a choice on columns with equal 
CENT's, since they can easily be bound to 
themselves. 
2. By binding unequal CENT's to equal names, we 
can choose this alternative. 
3. This is not optimal; all columns are kept. 
Projection will elimanate unwanted columns. 
The equivalence vector also presents the easiest form to 
deal with on a practical level; a complete equivalence 
relation indicating classes of equivalence by CENT would 


be very difficult to specify syntactically. 
° 

2? 
Ill) is the concatenation of ENT, (A) and ENT, (pe) where 


The equivalence vector for R(X) () y2O) (see Chapter 


kK and K' are the sorts specified by the user. To 
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output_expression) 


where the input expression is a regular expression which 
is "matched" to the input, and the output expression dic- 
tates how to transform the bindings to an output string. 


The regular expression syntax considered is as follows: 


Delimiters are: blank, and parentheses 

Operators are: or (|}, closure (*), not (*), and 
concatenation (e.g. a|b matches a or b, a* matches 
any number of a's, “a matches anything but a, ab 
matches ab). 

Special characters are: - (matches any character), 
$ (matches any number), ? (matches any upper case), 
! (matches any lower case), < (matches the beginning 
of a line), > (matches the end of a line). 

Bindings are made by /numeric, variable/ and are 
created only if the numeric expression is satisfied. 
The format of the numeric is n+ (n or more charac- 
ters in the string to be bound), n- (n or less), 
and combinations of these using concatention or or. 


Some examples are: 


RE Input Bindings 
<a*|b*/5-,x/> aaamp x > mp 
same aamnopqr none (will not match) 


albc/x/$# bemno231 x > mno 
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The user is referred to explanations of QED for fur- 
ther elucidation, and to Appendix C for a formal syntax 
definition. 

The main drawback to implementing such a parser is the 
lack of efficiency that code doing these tasks will have. 

It is necessary to, in effect, compile machine code from 
these regular expressions and execute that code. No attempt 
has yet been made to implement this design, although it is 


hopeful that the task is not too complex to undertake. 


Protection and The Projector (See Chapter II, Figure 2-3 for 
the part the projector plays in the system structure) 

A situation that is sure to arise is that of having 
privileged information which is not isolatable to a single 
data area or relation. For instance, the relation name- 
salary-contract-percentage might exist; salaries are con- 
fidential while contract and percentage are not. In effect, 
we are in the position of wanting to allow access to a 
projection of a relation. Given the MULTICS protection 
scheme (see Appendix D for a full discussion of protection 
issues), a need for a "projector" arises. This projector 
would operate in a ring higher than that of the user. The 
user would then have to request (through certain stringently 
defined entries) the projection he was entitled to via the 
projector. By having the relation in question only permitted 


to the higher ring of the projector, protection is gained by 
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limiting the user to accessing the relation via a well set 
forth sequence of code, the projector. 

The problem arises of some users of GOLD STAR having 
ring permission as high as would the projector. This brings 
about a manifestation of the ring uniquencss limitation 
(Appendix D) of MULTICS: that a user in your ring (here, 
that of the projector) must be given access to a segment 
on an all or nothing basis; you cannot force a gate upon 
him. 

Until such time as MULTICS allows gates to be imposed 
on a caller in the current ring, we must content ourselves 
with protecting on a projection basis only against those 


users in inferior rings to the system. This is the job of 


the: projector. 


The Common Usage Descriptor (CUD) (See Chapter II, Figure 2-3 
for an indication how the CUD fits in the system structure). 
The purpose of the CUD is to provide a description of 
the most common usage a relation receives. For instance, 
if a telephone directory were always to be accessed by 
“oiven a name, find an address and telephone" (rather than 
Meiven “an d@ddress...4.°",- 0r “piven a-number..<.'") > “the: CUD 
would somehow describe this and indicate that the ideal 
sorting of the directory would have name as its most ordered 
column. 


No design or plans have yet been made for the CUD, but 


ee a 


it is felt that as the complexity and number of RSM's pro- 
liferates, 2 device dike it will be needed for efficiency. 
The next chapter will now explain the specifics of 
the implementation. just described: ‘the -sibroutine calls, 
the programming considerations, and an example of the use 


of GOLD STAR. 
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CHAPTER V 


PROGRAMMING GOLD STAR 


1. The User Interface 

In this part of the thesis we will outline in detail 
the specific functional calls available from the GOLD STAR 
system. A few subjects are worth noting before a complete 
description is presented. 

Arrays 

GOLD STAR permits both pointers and arrays of pointers 

as input. This is an efficiency matter considered in 

a later part of this chapter, section 2. 

Nesting 

Since all calls in GOLD STAR are functional, calls can 

be nested. This means that whenever the result of an 

operation is appropriate, the function can be used as 

an argument to another call. For example, with a, b, 

c, d as pointers, 

(a) a=mgr$union(b,c) 

(b) d=mgr$union(mgr$intersect (a,b) ,c) 

Note that all characteristics of the result will be 

determined by the left-most argument. Hence in (a) 

a will be "the same as'' b (meaning if one is a quart, 

the other is a quart, likewise for relations; or, that 

the order of the CENT elements for a is the same as 


in b); while, with (b) 4d will be ''the same as" a. 


2905 
One other point: since PL/1 prevents us from returning 
arrays from a function, a pointer to an array is re- 
turned. We denote this by (p->)A where A is an array 
of pointers. This will affect nesting and assignment; 
a typical array nesting would be as follows 

D=mgr$union(mger$intersect(A,B)*E,C)7E 

A,B,C,D,E arrays of pointers, E based 
Notation 

1. All upper case variables denote arrays 

2. All lower case variables denote scalars 

3. (p->)A indicates a pointer to an array 

4. {} denotes a choice of elements contained 

5. [] denotes what is contained is optional 

6. "option" denotes a character string of one to 

three characters which can assume the indicated 
values as its characters 

7. Underscored variables are character variables 
Semantics 

1. q & Q refer to quart pointers 


2. r & R refer to relation pointers 


tl 


All arrays in a given expression using the GOLD 
STAR calls must have a lower bound of one and 
and identical upper bounds 

4. Meanings of options are: 


F 


i 


delete first argument when done (RSM) 


S delete second argument when done (RSM) 
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I = insert item being referred to (DSM) 


oO 
i] 


delete item being referred to (DSM) 
(I overrides D) 

1,2,....,9 = use this column of the quarts 

supplied as input (see get _data§&successor data) 

(DSM) 

E = treat first argument exactly as if it were 
expand quart(argl) -- this is an efficiency 
feature (DSM) | 

Only one DSM or RSM can be used per operation. 
This means that the RSM or DSM dictated must be 
the same for all elements of the arrays which 
determine the DSM or RSM to be used. 
Non-existent optional arguments are the same as 


if NULL were specified. 


New Relations 


Since an operation producing a relation (or a group 


of relations) must create new segments to hold these 


relations, the following procedure is followed to 


handie naming: 


1. 


If F option is specified, the new relation is 
given the name of the one to be deleted. 
Otherwise, the console is queried. This policy 
is changeable if the need arises for another 


approach to this case. 
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Error Handling 
This is handled by a system program called GS error. 
The user will receive a message of the form: 

Error XXX Internal opcode was y 
followed by two pointers, a name and pointer, or two 
names of interest (their meaning depends on the error 
code xxx) followed by an error message. Y is the 
internal code for the operation in progress and is 
indicated with each call description. Depending on 
the call form to GS_error, the user may be given the 
opportunity to return and continue from where the 
error occurred. The nature of the results will de- 
pend on the error incurred. Appendix G describes 
GS_error in greater detail. All error messages are 


stored in GS_err_messages with the a 


line being 
the message for error number k. 
The reader is referred to the PL/1 code listings of the 
manager which include all of the PL/1 structures used by 
the system (see Appendix F), and to Appendix E, which con- 
tains the important PL/1 structures in an annotated form. 
The operations are classed into six groups. They are: 
1. Pure set theoretic -- those outlined in Chapter III, 
section l. 
2. Ordered set theoretic -- those considered in Chapter 


III, section 2. 
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3. Structural utilities -- for conversion to and from 
quarts and relations, and to and from scalar quarts 
and arrays of quarts. 
4, ENT utilities -- for examination and manipulation 
of the ENT's. 
5. Token creation and maintenance -- the creation and 
examination of reference numbers in data areas. 
6. System Utilities -- for the creation, initiation 
and deletion of data areas and relations. 
Finally, the reader is referred to Appendix H which 
describes a useful debugging aid, and to Appendix I which 
contains simple examples of many of the operations per- 


formed on quarts. 


Be ic 


Pure Set Theoretic Operations 
union (un=abbreviation recognized) (U=internal opcode) 
q=mgr$un(q[,{1}] [,option]}) 
r=mgr$un(r[,{1}][,option]) 
(p->)Q=mgrSun(Q[, {$}] [,option]) 
(p->) Remgr$un(R[, {2}] [,option]) 
options: F,S 


This is the set theoretic union of the two arguments. 
A null second argument is interpreted as empty; i.e. it 
produces a copy of the first argument. 
intersect (in) (I) 
Forms as in union 
This is the set theoretic intersection of the two ar- 
guments. A null second argument produces a quart identical 
to the first except with no elements. 
difference (di) (D) 
Forms as in union 
This is the set theoretic difference of the two argu- 
ments. A null second argument produces a copy of the first 
argument. 
cart prod (cp) (X) 
Forms as in union 
This produces the cartesian product of the two argu- 


ments. The result contains a column for every column in 
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the inputs, with a tuple for every possible concatenation 


of each of the input tuples. For example, 


A null 


compose 


a ob c od a b c dad 

1 dIt1 21 31 1 11 21 #341 
X = 

2- 12 22 32 1 11 22 32 


Z. Ne Zi wb 


BY (ka 22. 552 


second argument produces a copy of the first. 


(co) (C) 


q=mgr$co(q[,{%}] [,eqp] [,option]) 


r=mgr$co(r{, tit] [,eqp] [,option]) 


(p->) Q=mgr$co (QL, {23] [, EQP] [, option]) 


(p->) R=mgr$co(R[, {3} ] [,EQP] [,option]) 


options: F,S 


The composition is performed in the following way: 


1. 


If there is an equivalence vector (pointed to by 


eqp) it must be of the form 
eqp -> width name(1) name(2) .... name(width) 


where width=sum of the orders of the inputs. 
Bindings are then made between the names in the 
equivalence vector (neq's) and the CENT's in a 


sequential fashion. For an example, take 


-95- 
input 1+ ab input 27 cd eqp > 4wxyz 


then the bindings are a-w, b-x, c-y, d-3. An ''g" 
(ampersand) in the equivalence vector causes a CENT 
to be bound to itself. eqp > 4 w & y §& above would 
produce bindings a-w, b-b, c-y, d-d. A null pointer 
for an equivalence vector has the same effect as if 
the vector were all ampersands. 

2. The resulting quart (or relation) will consist of 
one column (conceptually, in the relation's case) 


for each unique, non-blank neq. For example 


eqp > 4wxyz produces wxyz 
eqp + 4wxw2z_ produces wx Z 
eqp > 4w'" wz produces wz 


3. A TENT in the result is produced from a TENT from 
each of the inputs such that 

a. All input columns with identical bindings have 
an equal refno (which goes into the resulting 
column headed by the binding's name). 

b. When the above holds true, other columns from 
the result are filled from the other input 
columns bound uniquely to the result column's 
name. 

c. Columns bound to blank names are ignored. For 


example, given 
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produce the two lines Jones_33 Maple 783-8001 Ford and 
Jones 33 Maple 783-8001 Chevy. Had there been no listing 
for Jones 33 Maple in either of the directories, the result 
would not include him. 
project (pr) (0) 

q=mgr$pr(q,eqp[ ,option]) 

r=mgr$pr(r,eqp[,option]) 
(p->)Q-mgr$pr(Q,EQP[,option]) 
(p->) R=mgr$pr(R,EQP[,option]) 

options: F 

This projects out all columns whose name in the equiv- 
alence vector is blank. The width of the vector must be 
equal to the order of the input, and the values in the equiv- 
alence vector replace the original CENT's in the result. 


For example 


a boc eqp 3xy"" x Y 
yd 2h 1 11 
Tl lL. 22 yields 3 13 
a 13) —23 


Note that after a column is removed, any duplications in 
TENT's are deleted to a single entry. The ampersand may 
be used to indicate that the CENT for that column is to 


be unchanged. 
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Ordered Set Theoretic Operations 
sort (so) (S) 

Forms as in union 

This sorts the first input with respect to the order 
of the ENT of the second input. Both inputs must contain 
the same ENT elements, unless the second input is null, in 
which case the first input is sorted without change in ENT 
ordering. Note that the effect of sorting according to an 


equivalence vector can be had by saying 


q=mgr$so(q',mgr$me(q',eqp)) 


where eqp points to a vector containing the ENT elements 
of q' in the desired order (see modify_ent later on). 


successor relation (sr) (P) 


q=mgr$sr({1}[,q][,option]) 
(p->) Q=mgr$sr({2}[,Q] [,option]) 


options. F,S 


This produces the TENT in the first argument which is 
immediately greater than (in the lexicographic sense) the 
first TENT in the second input. If the second arg is null 
or non-existent, the first TENT in the first argument is 
returned. If there is no successor, a zero-length quart 
is returned. For example, 


given first input 


|p 
{Oo 
1a 


bs 


cr 


ic, 


pe 
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Structural Utilities 


convert_to.q (cq) (Q) 
q=mgr$cq({/}[,option]) 
(p->) Q=mgr$cq ({Q}[ ,option]) 
options: F 
The first argument is converted to a quart. 
convert tovr- Ger) «CR} 
r=mgr$cr({2},r[,option]) 
(p->) R=mgr$cr ({2},R[,option]) 
options: F 
This converts the first input to a relation with 
respect. to the RSM used for the second input. 
expand quart (eq) (T) 
Q=mgr$eq (q) 


This converts a quart of length n into an array of n 
length 1 quarts. 


squash array (sa) (T) 


q=mgr$sa(Q) 


This converts an array of quarts (with identical ENT's) 
into a single quart. Duplications in TENT's are not deleted, 
but the result is sorted. Care should be exercised not to 
allow duplications to hinder proper operation (the duplica- 


tions can be removed by projecting without removing any 
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columns: 
gemersprimerssai3?,eqp) (with appropriate equivalence 


vector) 
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ENT Utilities 
get_ent (ge) (E) 


eqp=mgr $ge ({2}) 
EQP=mgr$ge ({2}) 


This returns an equivalence vector containing the CENT 
portions of the input. 


modify ent (me) (M) 


q=mgr$me (q,eqp) 
r=mgr$me(r,eqp) 
(p- >) Q=mgr$me (Q, EQP) 
(p->) R=mgr $me (R, EQP) 


This changes the CENT portions of the input to the 
contents of the equivalence vector. The returned pointers 
are the same as the input. Ampersand (§&) may be used. 


clear_ent (ce) (Z) 


q=mgr$ce (q) 
r=mgr$ce(r) 
(p->)Q=mgr$ce (Q) 
(p->)R=mgr $ce (R) 
This clears to NULL the PENT portions of the input and 


returns the input pointer. 
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Token Operations 

At this point, it is well to point out a practical 
consideration which necessitates distinguishing a CENT 
element from a data type. It is possible that one would 
desire a relation such as employee-employer; but in this 
case, the reference numbers for employees and employers 
could refer to the same data type, namely personnel or 
name. To allow for the case where two CENT entries must 
be distinct, yet refer to the same data-type (and associated 
data area), the following convention is adopted: for all 
relational operations (RSM), the entire CENT is used; for 
all token operations (DSM) only the first four characters 
are used. Hence, we could have the relation name_employee- 
name_employer with both columns refering to the same data 
type "name". 

By way of explaining the PENT, let us first note that 
when a CENT is used by a DSM to indicate a data type (by its 
first four characters), this character name is associated 
to the data area by a pointer variable. This pointer is 
then stored in the PENT linked to the CENT in question. 
Then, in future references to the quart in question, the 
PENT's which are non-null can be used directly without 
incurring the overhead of translating the first four charac- 
ters of the CENT into a pointer to the data area. 

A final note: in discussing the following operations, 


q' will refer to the special case of an order one length 
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one quart. So, we will be talking about the CENT and the 


TENT of a singleton quart. 
get_refno (gr) (R) 


q'=mgr$er (d, {2°} [, sptr] [,ent] [,option]) 
(p->)Q' =mgr$gr (D, {YB°}[, sptr] [, ent] [, option] ) 
options: D,I 


d is a pointer to a raw data item such as string or 
an integer. This operation takes a data item and returns 
a singleton quart with the item's reference number. The 
data area used is determined by its name, type, or by a 
pointer to it (which is more efficient), dp(which can be 
obtained via MULTICS hcs_$make ptr routine or by the new_ 
data_type operation outlined in group six). The resultant 
CENT is type unless ent is specified, in which case that is 
put in. If an item is not in the data area, and I is not 
specified, a zero-length quart is produced; if I is speci- 
fied, the item is inserted, and the new reference number 
returned. With D option, the refno is returned despite the 
item's being deleted. sptr is an optional argument provided 
for certain DSM's where the user must indicate after which 
item an insertion is to be made; it is a pointer to another 
data item. 
get_data (gd) (D) 


d=mgr$gd(q[,type][,option]) 
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(p->) D=mgr$gd(Q[, type] [,option]) 
options: DB i572 3640 
This converts a reference number to a raw data item. 
The data area to be used is determined by type if specified; 
otherwise it is determined as indicated in the preface of 


on CENT, where n is the number option 


this group from the n 
specified (1 is the default). Basically the number option 
permits the user to choose which column of the quart to use. 


th column. 


The refno used is then the first in the n 

The E option permits an entire column to be operated 
upon since 
(p->) D=mgr$gd(q,"E"') =mgr$gd(mgr$eq (q) ) 
The E option is much more efficient, however. Finally, 
even if the D option is specified, the item is returned, 
but then deleted; references to non-existent items yield 
a result of NULL. 
successor data (sd) (S) 

q'=mgr$sd(q[,type] [,ent] [,option]) 
(p->)Q'=mgr$sd(Q[, type] {,ent][,option]) 

optvonss D E126 4<9 

The reference number and data area to be used are 
determined exactly as in get data, using the column number 
option, and CENT conversion. Waht is returned is a single- 
ton quart (with ent for its CENT if specified, else type) 
containing the reference number of the item which is 'next" 


after the input refno. The order on the data is determined 
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by the DSM, but reference numbers are always assigned such 
that numerical order is kept by the order on the data. 
Hence, successor data returns the next greatest refno which 
is included in the data area; the input refno need not be 
included in the data area itself. D options causes the 
deletion of the item whose successor was found, if there 
was one, not the successor itself. Finally, a null input 
or zero refno returns the first refno in the area, while 

if no successor exists (the input is greater than or equal 
to the last refno in the area), a zero-length quart is 


returned. 
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System Utilities 
initiate relation (ir) (Z) 

r=mgr$ir (name) 

This intiates the relation "name" and clears the PENT 
portions of the relation (this is necessary since each new 
process invalidates all stored pointers by virtue of the 
new segment numbers assigned). 
new relation (nr) (N) 

r=mgr$nr (name ,r) 

This creates a new relation by the name "name", and 
assigns to it the same RSM as the second input. 
new_data_ type (nd) _ (N) 

dp=mgr$nd (type , DSM) 

This creates a new data type "type" (which must be a 
name 4 characters in length) and assigns to it the DSM 
named "DSM". dp is a pointer to the new data area. 
kill_data_type (kd) (XK) 


a q 
NULL=mgr$kd({, an) 


This deletes the data type "type", if that is given, 
or deletes the data type associated with the first ENT 
clement of the input quart, if that is given. (See preface 


to group 5.) 
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2. Programming Considerations and Specifics 
The user is referred to Appendices E and F for the 

system structures which serve as interfaces, and for the 

code of currently existent modules. 
Special Functions of the Manager 
The manager serves to make the rigid calling sequence 
enforced by PL/1 less of a problem. In the formal 
language, it is not possible to omit arguments, or to 
have a choice of the form (pointer, string, etc.) of a 
given argument. For example, the call to kill _data_ 
type could not be handled by the standard PL/1 facili- 
ties (it takes either a pointer or string). The mana- 
ger overcomes this problem using a utility which ob- 
tains for the program a pointer to the arguments, but 
makes no interpretation (see cu_ in Multics Manual). 
The arguments are then treated, on a machine dependent 
basis, by code designed to test for argument types as 
well as contents. This code then permits the user to 
be free with his form and receive a diagnosis of trouble 
from GOLD STAR (rather than from MULTICS) which is more 
specific in its messages. 
The manager also serves a number of other vital needs. 
It contains all of the machine dependent code (except- 
ing area considerations, which are mentioned later). 


Segment and name-space management are handled by the 
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Arrays and Calls 
In MULTICS, the call and return sequence is relatively 
expensive, often taking the same time as fifty or more 
machine instructions. To minimize this overhead, GOLD 
STAR is designed to deal in arrays of pointers as well 
as in pointers alone. By this vehicle, the user can 
achieve the effect of iterative calls by passing instead 
whole arrays. The system routines then iterate within 
themselves, saving the need to iterate upon the calling 
sequence. Hence, the entire system is designed to 
effectively minimize the number of calls. Hence we 
find that the following two calling sequences are 
identical in effect. 
dcl (A,B,C) (n)pointer; 


dcl D (n) pointer based (x); 


A=mgr$un(B,C)+D; 
is the same as 


dcl (A,B,C) (n)pointer; 


do i=1 to n; 

A(i)=mgr$un(B(i),C(i)); 

end; 

The second is less efficient due to call overhead. 
Paging 

Care must be taken that a minimum number of pages are 


requested in a limited period of time. Otherwise, 
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excessive waiting for pages will ensue. Basically, 
only two remedies are available: limit code as much 
as possible to linear flow without external calls, 
and localize external references to a given page. 

The modular construction of GOLD STAR lends itself to 
these restrictions; most modules have approximately 
linear flow, and during a given task, usually only a 
strategy module, a data area (or relation segment), 
and the free free segment (dynamic allocations) are 
needed. There is virtually no intercommunication 
needed among the various system components other than 
in a simple linear transfer of control. 

Frequent Trouble Spots 

One of the most troublesome errors to encounter is 
that that of passing around erroneous pointers. The 
system takes care not to permit null pointers to be 
transmitted where they are going to cause a MULTICS 
error. The user must be very careful not to use 
uninitialized or incorrectly set pointers, as they 
can cause disaster. 

GOLD STAR makes extensive use of allocations, and, in 
fact, returns all values in based allocations. The 
user should beware of filling up this free free area; 
the system cleans up where possible, but cannot do so 


in some cases. For instance, when a pointer to an 


a Oe 


array of results is returned, that array must be 

freed by the user to clean up properly (single returns 
are handled by the system). 

Dynamic Storage 

GOLD STAR is suitable for manipulation of large aggre- 
gations of data. At any one time, however, only a 
small portion of the collection need be accessible 

to user and system programs. In addition, GOLD STAR 
utilizes a certain amount of ephemeral storage in the 
form of QUARTS. In order to reduce the amount of 
storage required at any one time the free storage 
facilities of PL/1 are frequently invoked. Thus QUARTS 
and some character strings exist only as long as a user 
deems necessary. 

In addition to those instances where ephermal data is 
used, data-reference number bindings are stored in a 
PL/1 accessible AREA. This feature, also used by 

RSM _Q, allows effective management of data which is 
dynamic in nature, without explicit storage management 


by the user. 
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/* grade list contains: "semester", "subject _number", 


"letter grade", 'student_name" */ 


compose ptr=mgr$cart_prod(mgr$cart_prod( 
mgr$get_refno(F ptr,"letter grade"), 
mgr$get_refno(subj_ptr,"subject_number)), 


mgr$get_refno(term_ptr,"'semester")); 


is this forms an order 3 quart with the CENT's "letter_ 


grade", "subject_number", and ''semester" =F 


fi_ptr=mgr$compose(compose_ptr,fi_ ptr); 


failed ptr=mgr$project(fi_ptr,addr(names)) ; 
/* now get addresses of the names already obtained */ 


fi_ptr=mgr$initiate relation("student_directory") ; 
fi_ptr=mgr$compose(fi_ptr,failed ptr); 

call labels (fi_ptr); 

return; 


end; 
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AUTHOR COMMENTARY -- L. ALAN KRANING 


ASPECTS OF THE MODEL 


The development of any large system must presume that 
certain trade-offs will be made during the implementation 
phases, but there are certain pre-implementation and pre- 
development considerations that have far more significant 
impact than the actual generation of a working system. 
First of all, the needs which motivated the design of the 
system must be considered in detail. The GOLD STAR system 
is suitable for administrative data management needs for a 
university such as M.1I.T., but it is not at all obvious 
how well such a system would perform in other environments 
where the decision structure were different. Second, de- 
Spite the generality of set theory, the GOLD STAR model 
presented in Chapter II reflects my biases, the biases of 
my thesis partner, and biases of those who will use the 
System about the nature of relatedness. An exact defini- 
tion of "a is related to b" is difficult to produce without 
using words as nebulous as "related''. What do we mean when 
we say that "John" is related to "Dodge'? Difficulties in 
this area -- especially in determining what relations are 
and are not properly included within a data-base -- ultimately 
determine the utility of our model. 

The nature and degree of trade-offs in GOLD STAR revolve 


about some conflict between the unordered nature of sets and 
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the ordering of storage in computers. Retrieval of ele- 
ments from sets is not well specified, but since sets and 
operations on them are abstract, this is not severe. 
However, in an environment where sets must be represented 
as bit strings in a totally ordered memory, we must specify 
an algorithm for retrieval of any item, as well as speci- 
fying its representation. Large scale associative memories 
would aid in representation of sets, but current technology 
and economics of implementation now preclude such a situa- 
tion. 

The quart construction saves storage space by ''fac- 
toring" the data type names out of a relation. However, 
many to one relations such as the name-friend relation 
would replicate many data elements when considered as a 
quart. While the quart imposes ordering implicitly by 
storage address, it suffers the same malady of other data 
structures: retrieval of information must somewhere take 
into account an immutable order on memory. The notions of 
dynamic storage management and pointer data elements allev- 
iate part of this burden, but only at execution time. The 
programmer must completely specify, or accept someone else's 


specification, for a mapping between sets and storage cells. 
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AUTHOR COMMENTARY -- ANDREW FILLAT 
ASPECTS OF THE IMPLEMENTATION 


There is a distinct dichotomy of feelings which accom- 
pany the birth and early life of GOLD STAR. 

On the positive side is the most important feature of 
all: the framework of the system; once truly familiar to 
a user, it is one that reduces many exceedingly difficult 
data problems to amazingly short and simple algorithms. 

It was, in fact, hard to come up with a non-trivial example 
(at least from the coding standpoint). 

In addition, on the positive side, is the vast open 
space that GOLD STAR can expand to. As special data hand- 
ling needs arise, new strategy modules can be written to 
increase efficiency, without ever redesigning the options 
which use the system. 

The apprehensions are attributable in great part to my 
inherent skepticism. There are many nagging doubts at this 
point of how marketable the entire MULTICS system really is. 
GOLD STAR, though not designed for MULTICS alone, depends 
upon its host for many of its nicest features and conveni- 
ences. It seems a loss to create a one-of-a-kind system, 
even if it becomes an integral part of the installation. 

The issuc of efficiency is also a nagging one. There 
is no way to my knowledge that one can test the design of 


a module under heavy loads until enough of the entire system 
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is available to create such a load. Hence, there is little 
way to elicit the performance of the system under production 
conditions. Although indications to date are excellent, it 
somehow sits uneasily upon me to be forced to design such a 
complex entity as GOLD STAR so empirically. 

My final and I think most serious doubt is the possible 
"understanding gap''. After conceiving, creating, and devel- 
oping GOLD STAR in collaboration with the co-author, the 
system has become a perspective on my thinking. It is dis- 
turbing to realize how difficult it is for a detached but 
interested party to conceive of the system or his problem 
in light of the system. It is my hope that the systematic 
(albeit untested) approach presented through this disserta- 
tion will allow a user to become familiar with our set the- 
oretic conception of data. 

Finally, I would hope that a wide range of users would 
be willing to tackle the job of learning about GOLD STAR. 

I am convinced that the entire administration of M.I.T. 
could use GOLD STAR to handle virtually every part of its 
problems and assignments. It is my hope that these other 


people will sce the tremendous value in our system. 
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APPENDIX A 
A LEMMA ON THE NESTING OF PROJECTIONS 


Lemma I. WaT R(X) = Tan BROOD = Tam sR(x) 


Proof: 
if X = domUR(x) then by the definition of 


projection in (3-8) 


Tm R(x) = {f£:XNB-N, | (3g) (geR(x) & fe g)} 
Thus, 

T\TpR(x) = {h: AN (XNB) +N) | (3g) (geR(x) &h =g)} 
But 

AN(XNB) = XN(ANB) = XN(BNA) 
So 

T,TRR(X) = TanpR(x) = TR™AR(X) 

Q.E.D. 
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APPENDIX B 


ALPHABETIC ORDER AND REFERENCE NUMBERS 


Data types ordered by alphabetic sequence will usually 
be large in size, typically of the order of 107 or greater. 
Many types will be highly active in numbers of insertions 
and deletions. The large size of any data type poses no 
significant barriers if the number of bits composing a 
reference number is sufficiently great; the MULTICS imple- 
mentation of GOLD STAR uses a 35 bit reference number, 


34 4 2 17.8 


which limits the size of any data type to 2 
billion data elements. The ability to insert and delete 
items with impunity is more problematic. Insertion of an 
item requires sparseness among reference numbers if well 
ordering is to be maintained. Furthermore, when either 
inserting or deleting an item, it is of utmost importance 
that previous string-reference number bindings remain un- 
affected. Alteration of any binding necessitates a sub- 
sequent search and modification of all relational structures 
where the binding was assumed valid; in large data bases this 
process becomes prohibitively expensive if frequently per- 
formed. 

One strategy which adequately serves the needs of dy- 
namic binding is the binary tree concept outlined in Chapter 
4. The illustration in Figure B-1 extends the tree dis- 


cussed in Chapter 4. Inside each node above the data element 
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Figure B-1: The "names" Data Area 


~123* 


name is a bit string which, when read left to right, indi- 
cates the left and right turns required to reach an item 

in the tree. For example, to reach the root node, no turns 
are required, and to reach "Donald" turns to the left, 
right, left and right (0101) are called for. Two problems 
prevent direct usage of these "path trace'' numbers as 
reference numbers. First, since all reference numbers are 
36 bits long, the "path trace" numbers 00, 0, 000, and 0000 
would be indistinguishable, as would be the set 101, 1010, 
101000000, and 10100. Second, the bit strings serving as 
path trace numbers do not preserve the well ordering among 
the data elements. For example "George" lexicographically 


precedes "Milton", yet path _trace 10 is greater 


George 7 


than path_trace 1. Uniqueness of reference numbers 


Milton — 
and preservation of order will both prevail if we adopt the 


following schema: 


Assume that a word of storage identifies bit positions 


as below: 
most significant least 
| bit (msb) | Significant 
bit (lsb) 
n 210 
sign bit 


th 


Without loss of generality, we let the i bit position 


i =n-l, n-2, ...3, 2, 1 hold the flag, 0 or 1, for 


left and right turns respectively to be taken once we 


jth 


reach the level of the tree. Note that a tree of 
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maximum depth n will require n bits for representation 


of path trace numbers. 


Assume that the first 1 bit starting from the right 
indicates that all bits to its left are significant 
in a path trace. Thus the path left-left-right-left- 
right would result in a path trace 00101 and a refer- 


ence number 


path trace number 


00101190000000000000000000000000000 
ta 
sign path trace flag 
Figure B-l shows reference numbers below each node 


both in binary and decial. Thus if a data item is 


found at depth k of a tree, its reference number can 
d ; 

be expressed as (£ a, 2*) + gk-1 
i=k ; 

1, =" Ree le edges (2* in binary is represented as 


with a, = 0 or 1 for 


al bit in position i, if the bits are labeled as dis- 
cussed above.) To compute a reference number from a 
string, we set i= d, and then compare the given string 
with the root datum. If equal, the reference number 

is 2°. 1f the given string is less than the root, the 
reference number is 0-22 + the reference number ob- 
tained by 1) changing the "search" node to the root's 
left descendant, and 2) reducing i by 1. An analagous 
procedure applies to the right. If the given item is 


greater than the root node, then its reference number 
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is 1°27 + the reference number obtained by 1) changing 
the "search" node to the right descendant, and 2) re- 


ducing i by l. 


Notice that at each step of the search, reduction of 


the value of i will ensure ref#(a) < ref#(b) «> a < b. 


Overflow of the Binary Tree 

Figure Bl illustrates a tree structure resulting 
from one of many possible input sequences for the data type 
"names". Although the tree is not optimal, i.e., all nodes 
in which both descendants are missing lie on either level i 
or i+41, fine bits are sufficient to contain all reference 
numbers. What happens, however, if we attempt to insert the 
item "Cyrus''? If we descend the tree searching for an in- 
sertion position, this item would logically be the left 
descendant of '"Dan''; however, such an insertion cannot be 
made with a five bit reference number; hence we must restruc- 


[Al] algor- 


ture the tree before inserting "Cyrus". The Ness 
ithm for restructuring trees to optimum depth yields the 
form in Figure B-2. The restructuring process destroys 

the entire set of old bindings; to retain the viability of 
relations and quarts in which the original bindings parti- 
cipuated, a quart is produced, relating new and old reference 
numbers for each member of the data type. At restructure 


time, the user is informed of tree overflow, and the exis- 


tence of the new-old-refno quart. He then performs composi- 
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Figure B-2: Restructured ''names' Data Area 
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tion of this quart with the necessary relations. The tree 
overflow problem will in practice arise very infrequently; 
however when overflow does occur, it is mandatory that 


recovery procedures by operable. 


Randomizing The Input Sequence for dsm_astring 

Referring to Figures B-1 and B-2 we note that the 
particular organization of that tree depends to some extent 
upon the sequence in which data elements are entered. In 
particular, if we insert a large number of data elements 
which are input in alphabetic order, then the tree will 
quickly overflow. Alleviation of this problem is accom- 
plished by scrambling large sets of input data prior to the 


binding process. 
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APPENDIX C 


<Regular Expression>=::<EXP1>/<NUMERIC EXP><VARIABLE> 
<EXP1>=::<EXP2>|<EXP2><OR><EXP1> 
<EXP2>=::<EXP3>|<EXP3><EXP2> 
<EXP3>=::<PEXP4>|<PEXP4>* 
<PEXP4>=::"<literal>"|$[?]!/.|<|>|*<PEXP4>| 
(<Regular Expression>) 
<NUMERIC EXP>=::<NUMERIC EXP1>|<NUMERIC EXP1><OR> 
<NUMERIC EXP> 
<NUMERIC EXP1>=::<NUMERIC EXP2>|<NUMERIC EXP2><NUMERIC EXP1> 
<NUMERIC EXP2>=::<NUMERIC EXP3>|<NUMERIC EXP3>+| 
<NUMERIC EXP3>- 
<NUMERIC EXP3>=::<digit strings> 
<VARIABLE>=::<character strings> 
definitions: <OR>=| 
$ = any digit 
? = any upper case character 


! = any lower case character 


lit 


anything 


< left anchor 


> 


it 


right anchor 
Note: any special character appearing twice in succession 


is interpreted as one of itself. 
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APPENDIX D 


PROTECTION ON MULTICS 


1. The Basic Concepts 

Each segment in MULTICS possesses an access control list 
(ACL) which lists all processes which may access that segment, 
and the restrictions on that access. There also exists a com- 
mon access control list for each process (CACL) which can be 
viewed as simply an ACL common to all of a user's segments. 
The possible forms of access are read (R), write (W), execute 
(E), and append (A), or no access (this appears as a blank in 
the ACL but will be signified by either - or X). It should be 
noted that by process, what is meant is a thread of control; 
i.e., no matter who the segments “belong to", a series of calls, 
returns, and execution represents the thread of control of a 
process. It is important to note the ACL discriminates by this 
process concept. 

As well as an REWA attribute, each process listed in the 
ACL possesses a ring bracket, of the form a:b:c. This ring 
bracket specities the action the supervisor will take upon a 
call from this listed process depending on which ring the 
calling process is in. The general concept of rings is merely 
an extension of the two state system to 64 states; operations 
permissible (in this case, by operations we mean access and 
calls) grow progressively more restricted as we move out from 
ring 0 to ring 63. Part 3 is a discussion of how rings work, 


and the following diagram should indicate how rings serve an 
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analogous purpose to states. 


Ring bracket listed 
in called segment a : b : c 
for calling process 


Calling process tans 2 7 ’ 
in ring 0-(a-1) a-b (b+1)-c (ct+1)-63 
Effect: of a-call: Legal Legal Legal if Illegal 
New Ring=a Ring call is to 
Unchanged “gate 
New Ring=b 
Effect of non- 
Call access: Illegal Legal Illegal Illegal 


This is all subject to the REWA permission listed for the 
calling process. In words, the essence of this ring bracket 
is as follows: if the calling segment is in the first speci- 
fied range (a to b), then all forms of access are legal, and 
no ring changes occur; if the calling segment is in the second 
range (bt+tl to c), only a call is permitted, and this generates 
a “gate crossing fault" (the fault is analogous to the excep- 
tion generated when a problem state program makes a call on 
the supervisor; entry to the more privileged routine must be 

at specified places, or 'gates'); if the calling segment is 

in the low outside range (less than a), only a call is per- 
mitted, and an "attempt to execute data fault" is generated 
(the name is misleading as Part 3 indicates , but the 
situation is analogous to a supervisor calling a problem 
program-care must be taken to allow the less privileged called 
program only the arguments passed to it, and not to allow any 


access to the calling programs' more privileged data); if the 
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calling segment is in the high outside range (greater than c), 


no access is allowed. 

This gate scheme has distinct advantages over a simple 
two state system. First, by using ring 0 for the supervisor, 
the HCS can be fully protected from undesired access by speci- 
fying a ring bracket of 0:0:i (i any other ring) for all pro- 
cesses. Yet, under this view, the HCS becomes merely a copy 
of code available to everyone; system processes (usually 
called daemons) can run in any ring, and still have full 
access to the HCS if its process is permitted from any ring, 
without allowing other users unrestricted access. The second 
major advantage is almost a corollary to the first; by writing 
a sub-system in ring i, any user can possess supervisor type 
privileges over his system by having his users in ring itl. 
The logical consistency of this plan is clear: the HCS is to 
its sub-systems as the sub-system is to its users. Since each 
user can itself be a sub-system, the uniformity of this scheme 
is fantastic. The ability to assign access on a per process 
basis, combined with the refined and extended system of states 
-- the rings -- leads to a computer system which is virtually 
tailored to the sub-system writer as well as the average, 
albeit necessarily skilled, user. 

There is one major limitation upon the flexibility of the 
ring system. I shall call this the "ring uniqueness limita- 
tion". The name describes the fact that if a user has privi- 


lege to some ring, then there is no way that another process 
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with the same ring privilege can permit access to the first 
process on a subordinate basis. For example, if Jones has a 
sub-system in ring 3 (his users run in ring 4), and Smith has 
ring 3 permission, then Jones must make the all-or-nothing 
choice of whether to give Smith unrestricted access or no 
access at all. This situation is clearly one that does arise 
on any large system like MULTICS, where there would be much 


demand for equal and independent sub-system space. 


2. Eliminating The Ring Uniqueness Limitation 

Eliminating the aforementioned limitation is clearly a 
useful and advantageous goal to adopt, at least from a theo- 
retical aspect. What would result would be a totally control- 
lable environment of sharing, where the level of privacy could 
range from zero to total. There is, however, a serious ques- 
tion of whether any scheme could both remove the restriction 
and not cost dearly in overhead. 

Three different schemes are presented which, through 
different approaches, would eliminate the MULTICS restriction. 
These ideas are the creation of non-concentric rings, the use 
of procedure as well as process access control, and the effect- 
ing of a trap mode of access. It is not possible for the 
author to make detailed analysis of the implementations or the 
overheads, for simple lack of facts; however, general assess- 
ments based on a knowledge of the system overview and the ring 


system will be made. 
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A. Non-concentric Rings 


The idea of non-concentric rings is a reasonably simple 
conceptual extension of the current ring system. A diagramatic 


presentation would be the best introduction. 


CNRRENT 
MANLTICS 


NON-GatcentRic RINGS 


The non-concentric rings (NCR's) would effectively define what 
might be called a "sub-system context". The advantageous fea- 
ture of this system would be that a user might have ring 3 
permission in his own sub-system context, and have only ring 5 
permission in another such context. The NCR's would isolate 
sub-systems into their own branch of the tree, and would even 
define independent scopes of authority on the higher level 
rings. The NCR's permit allotment of sufficient privilege 
without the allocation of over-sufficient permission. 

A major problem would certainly be the excessive space 
required to store information about ring status. In its full 
extension, NCR's would have a theoretically infinite number 
of subrings at every level. A practical solution, which is 
not especially costly in a theoretical sense, is to have a 
binary tree structure for the ring system. There would be 


one ring 0, two ring 1's, four ring 2's, and so on. Under 
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this plan, a process' place on the ring tree could be deter- 


mined using n+l bits, where n is the number of levels in the 

tree (the one extra bit would be used as a flag to mark the 

end of significance in the left to right scan of the binary 

bit string). The following diagram indicates the binary for- 

mat employed. Note that the binary method places a restriction 
on the operations staff: sub-systems must be placed on a low 
enough level to permit space enough for all the co-equal systems. 
In practice, ring 6, 7, or 8 would be the likely location for 


the average sub-system (thus permitting 64, 128, or 256 sub- 


systems). 
Tree Structure of Rings 
Ring level 0 ELOO0O 8 sxe co% 
Ring level 1 11100.4..1A 10100... .1B 
Spay ee eee 101100...2BA 100100....2BB 
level 2 


There is another major problem involved with the use of 
the NCR's. That is, how do we determine faults? Clearly, 
there are two types of faults (disregarding the distinction 
between upward and downward): the standard type -- as from 
2AA to 1A -- and a tree-crossing fault -- as from 2AA to 1B, 
the dotted line. The standard upward and downward faults are 
easily determined by being on connected branches -- simple up 
or down movement on the tree -- and would be handled exactly 


as in MULTICS. The tree-crossing fault presents a problem: 
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if we allow faulted access to gates across the tree, we run 
into tremendous problems specifying what corresponds to a 
ring bracket. A variable length list would be needed for each 
entry in the ACL specifying from which branches of the tree a 
process could call from. Another problem: how does the system 
distinguish between the faults? 

A possible solution to these problems might be to not 
allow cross-tree access at all. Then, the system could search 
for rings by simply following the branches of the tree. A 
cross-tree access would be detected if the system has to change 
direction in its tree search; i.e., if the tree search required 
going up and then down branches. Ring brackets would remain 
unchanged, and would only refer to the branches of the tree 
reachable without a cross-tree fault arising. For example, 

a segment would be specified with brackets like 1A:2:3; this 
would permit access unrestricted from 1A,2AA, and 2AB, and 
faulted access from rings 3AAA, 3AAB, 3ABA, and 3ABB. 

But note that this solution requires one important addi- 
tion to the features allowed a process: a process would have 
to be able to change its current ring so as to be able to 
reach all rings to which it is permitted. That is, a user 
with ring 1A permission who wishes to use a system in ring 1B 
must be able to change his ring to the 2BA he has been per- 
mitted to by the 1B system writer. This ring changing facility 
would require changes to the supervisor which would maintain 


a list of permissible rings for each process (currently, this 


ASO 


list has only one entry). Facility for users to grant appro- 
priate permissions would also have to be added, with appro- 
priate safeguards, such as another list for acceptable ranges 
into which permission might be granted. 

The system of non-concentric rings is conceptually the 
most rigorous solution to the ring uniqueness limitation of 
MULTICS. In its ideal form, with cross-tree faults being 
treated analogously to regular faults by use of an expanded 
ACL, the system should be easy to use, albeit difficult to 
implement. In the modified form, with cross-tree reference 
allowed only by a conscious change of rings, use would be more 
complicated, but implementation possibly easier. In any form, 
this system would be difficult to implement, and might not 
prove the best way to overcome the restriction of ring unique- 


ness despite its conceptual advantage. 


B. Procedure and Process Oriented Access Control 

The principle involved with this method of overcoming the 
ring uniqueness limitation is a very simple one. As well as 
specifying what processes may access a given segment, a user 
could also specify from what procedures (segments) these pro- 
cesses could issue the ‘calls:. A. sample version of the ‘current 
and extended ACL's might show how such a specification would 


appear, 
Current Form 


Multics.Jones.* RE 1:1:8 


Admin.Smith REWA 1:6:63 


Thor 


Extended Form 


Multics.Jones.* System.Andy RE 1:1:8 
Admin. Smith Exec. * REWA 1:6:63 


What this form of extension does is to specify from what 
procedure a process must make a call to be permitted. In 
the example, only if Smith of the Admin project were calling 
from a segment named Exec.something would he be allowed 
access. 

The above scheme does circumvent the ring uniqueness 
restriction by allowing a sub-system writer to specify that 
his segments are callable only by other segments of his sys- 
tem. This would then prohibit other users, even those with 
high enough ring permission, from accessing critical segments 
on their own. As long as the dispatching segments which 
could be referred to by outside programs were permitted only 
to execute (and not to be modified), the integrity of the 
calling sequences could be maintained. 

There clearly are limitations on this type of system. 
Space would certainly prove some sort of factor where it was 
necessary to specify complex lists of permitted callers. 
Some degree of overhead would certainly be introduced in 
checking the validity of the calling procedure. This method 
would go to pot if write permission were involved at any 
level. But a more fundamental problem might be the mainte- 


nance of the integrity of pathnames. Although pathnames are 


-138- 


unique, there seems to be no assurance that a clever pro- 
grammer could not pass to a called program an erroneous 
pathname. If the system were to completely handle identi- 
fication of calling procedures, the overhead involved in 
verification might prove unworkable. 

Though this plan has merit as a conceptually simple 
one, it would be a hard plan to carry out effectively. Safe- 
guards would be required against tampering with name conven- 
tions, and proper permission specifications by users would 
become more crucial and difficult to keep track of. This 
scheme might, however, be the easiest to implement, at least 


relative to others. 


C. Trap Mode 

From an efficiency of operation standpoint, the effect- 
ing of a trap mode of access would be the best solution to 
the ring uniqueness problem. A specification of trap mode 
for a calling process would automatically invoke a trap pro- 
cessing program upon issuance of a call. This trap processor 
could do anything, including freeing the caller from future 
traps on the same segment. In the case of ring uniqueness, 
a sub-system writer could assure that the caller was in a 
properly low ring by specifying trap for all calls from 
rings too high (low in number). The advantage of this method 
is obvious: special action is taken only on invalid refer- 


ence attempts; valid access will generate a zero overhead. 
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The problems in implementation are considerable. They 
would include such items as maintaining the integrity of the 
trap procedure itself (note that if the trap procedure is run 
under the calling process, the caller has permission to exe- 
cute, and might find it useful to run the trap procedure 
independent of any real trap). Disabling the trap for a 
fixed period might also be difficult to accomplish without 
loss of efficiency. In fact, though the original plans for 
MULTICS included provisions for a trap Gale of access, com- 
plications in the design forced its exclusion from the cur- 
rent system. 

A proposal for the inclusion of trap mode is outlined 
below. To the author's knowledge, this plan is feasible, 
although shortcomings in the interprocess communication 
facility would make a completely tight, safe system difficult. 
This shortcoming will be mentioned and considered later. A 
diagram would illustrate the basic operation of the system. 


The name appearing above each segment indicates its owner. 


HCS Trap Daemon 


Trap ~ O77 77 User Trap 
: Handler 
Ring 0 Processor Invoker 


System Generated 


Smith's Handler 


Ring i 


access] Jones T 


Daemon RE 
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mine who had desired its activation. Argument passing 
presents a related difficulty to the system. 

The only possible solution under the current system 
design is to employ an array of ''mailboxes". These would 
be segments possessed by the trap daemon, and allowed on a 
one per user basis to other processes. The daemon could 
then determine who had issued the IPC by checking the mail- 
boxes; he could be assured that the proper process has issued 
the request because only one process is permitted per mail- 
box. The two potential difficulties that arise are space 
requirements, and the possible confusion of sequence brought 
about by the asynchronous nature of the IPC requests. 

An implementation of trap mode, though not allowing as 
complete a flexibility as would non-concentric rings, would 
certainly provide that extra leaway of freedom to expand 
upon the available sub-system capabilities. The ring 
uniqueness limitation would be eliminated in an indirect 
way. Those programs which require special screening due 
to ring permission would experience considerable overhead, 
but those permitted only to low rings (high in number) 
would be unaffected by the safeguards imposed through trap 
mode, Trap mode is certainly not an easy concept to imple- 
ment, but it might well prove a worthwhile investment in 
time and effort. 

Eliminating the single big restriction of the MULTICS 


protection method is to be a virtual necessity as the size 
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and applicability of the system increases, and more sub- 
systems come under its purview. Which of the three methods 
outlined is taken, or whether another method is used is not 
so crucial. It is most likely that overheads, and not theo- 
retical advantage, will determine the final choice. It is 
hard to divorce oneself from the idea that a free sharing 
environment is the ideal, given the ability to totally 
regulate its scope. It is this idea of a full range -- from 
total privacy to total sharing -- that must be the ultimate 
goal of protection design. 

Just as generalization brings flexibility, it also 
brings overheads and time consumed where the activity might 
have been foregone. It is the ultimate futures of MULTICS- 
like systems which will bring at least a statistical answer 


to the trade-off at hand. 


3. How Rings are Implemented in MULTICS 

Associated with each process is a set of descriptor 
segments, one for each ring in which the process has access 
defined in the ACL by ring brackets. A schematic represen- 
tation would prove useful: (x=no access; i=any ring of 


higher number) 


Segment name DS 0 DS 1 DS 2 DS 3 DS 4 ....DS I Bracket 


in ACL 
aaaa R RE x x x Ll:l:i 
bbbb R R RE x x 2:2:1 


ecee R RE RE RE x 1:3:1 
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The ring of current execution is determined by which des- 


criptor segment (DS) the descriptor base register points 


to. 


The following enumeration of cases describes how the 


file system uses rings. 


A. 


D. 


cece calls or refers to bbbb; current ring is 2 


All attempts at access are legal, as governed by the 


RE permission. 


bbbb calls aaaa; current ring is 2 


1. no access is found in the ring 2 DS; a gate crossing 
fault causes the gatekeeper to obtain control (the 
gatekceper is conceptually an independent overlord) 

2. gatekeeper examines DS 0-1 for E access in aaaa 

3. if access is found, first ring in (highest number) 
is used; third element of bracket is checked to 
assure call is from a valid ring 

4. referenced entry point is validated as a gate 


S. 1f all is OK, DBR is loaded to point to DS 1 


bbbb refers to aaaa; current ring is 2 


Non-call references are illegal; the effect is the 
same as accessing another segment with no permission 


at all. 


aaaa refers to bbbb; current ring is 1 


Read is permitted; WA is permitted only if the ring 
bracket of bbbb includes the current ring in the 


first range (a:b). 
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E. aaaa calls bbbb; current ring is 1 
1. since there is read permission, an attempt to 
execute data fault is generated, and the gatekeeper 


takes control 


tO 
. 


gatekeeper checks DS 2-63 for E access 

3. first ring down with E is used; no gate is checked 
for 

4. DBR is reloaded to DS 2; appropriate arguments are 


made available to the lower ring bbbb 


There is one safeguard worth noting. The system will 
not allow a ring bracket to be assigned to any segment such 
that any element of the bracket specifies a ring lower in 
number than the ring it is being created from (the current 
ring). Thus, a user in ring 2 cannot assign 1:1:3. This 
guards against a user writing a lower number ring routine, 
and then transferring to it, thereby giving him higher 
level privilege than he should have. 

One other note: a called segment will run in the same 
ring as the caller is in, unless a fault is generated; in 
that latter case, the new ring will be the nearest ring 


numerically to the calling ring. 
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APPENDIX E 
SYSTEM INTERFACES 


1. User to System Interface 

The option writer or user of GOLD STAR needs basically 
the PL/1 environment and temporary storage facilities, and 
a collection of segments which he wishes to use with the 
system, and which were created by it. He need have no knowl- 
edge of the segments except their names, and the data types 
they contain if they are relations. In the case of DSM's, 
the segment name is the data-type. With RSM's, it is suggested 
that the segment name reflect the data-types related (e.g., 
the relation segment "name addr" should relate data types 
"name" and "addr". 

The user deals with GOLD STAR exclusively with pointers, 
segment names, and strings (see section V-1). There is a 
very small group of items to which these pointers refer: 
quarts, relations, equivalence vectors, ''data'', and data areas. 
The structures are described as follows: 

declare 1 quart based (quart_ptr) 

2 ID fixed binary (35) initial (0), 

2 length fixed binary (35), 

2 order fixed binary (35), 

2 CENT (allocation order refer (order) character (32), 
2 PENT (allocation_order refer (order) pointer, 


2 TENT (allocation_length refer (length), 


-146- 


allocation order refer (order)) fixed binary (35); 
declare 1 equivalence vector based (equiv ptr), 
2 width fixed binary (35), 
2 element (allocation_width refer (width)) character(32); 
declare 1 data_item based (data ptr), 
2 length fixed binary (35), 
2 string character (allocation_length refer (length)); 
Note that the data item definition is merely a way of describing 
a based varying character string. The relations and data areas 
are PL/1 areas with the first allocation containing as its 
first item the character (16) RSM or DSM name respectively. 
All other names and character strings are assumed to be 


fixed strings of whatever length is called for, if any. 


2. Internal Interface 
The manager translates the rather free form of arguments 
it receives into one of two structures for RSM's and DSM's. 
These argument structures are the sole communication between 
the system modules. 
The following is an annotated version of the PL/1 struc- 
tures used: 
declare 1 dsm_arguments based (arg ptr), 
2 upper_bound fixed bin(17), This tells how many ele- 
ments were in input arrays 
2 column_index fixed bin(17), This is the 1, 2, ... 9 


option 


xpaqe 

2 operation code character(1), This tells which oper- 
ation is to be performed 

2 d or _i option character(1), This contains either 
"D' or "I" if called for 

2 e option character(1), This contains "E" if called 
for 

2 data_area_ ptr pointer, This is filled in by the 
manager from the appro- 
priate given information 
(CENT, PENT, or given 
name ) 

2 data_or_quart ptr (limit refer (upper_bound) ) 

pointer, These are the first arguments 

2 return_ptr (limit refer (upper_bound)) pointer, 
These are for the re- 
sults. If sptr's were 
provided in a get_refno 
operation, they are put 


in here. 


declare 1 rsm_arguments based (arg ptr) 
2 upper_bound fixed bin(35), This gives the upper_ 
bound of the input arrays 
2 operation_code character(1l), This tells the opera- 


tion to be performed 


to 


quart 1 ptr (limit refer (upper _bound)) pointer, 
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2 relation 1 ptr (limit refer (upper_bound)) pointer, 

2 quart 2 ptr (limit refer (upper_bound)) pointer, 

2 relation 2 ptr (limit refer (upper_bound)) pointer, 
These are the inputs. 
The manager determines 
whether they are quarts 
or relations and places 
their pointer in the 
appropriate slot. Non- 
existent arguments are 
null. 

2 equivalence vector (limit refer (upper _bound)) 

pointer, These are the equivalence vectors for com- 
pose. Other operations 
needing eqv place the 
pointer in quart 2 ptr. 

2 return_ptr (limit refer (upper_bound)) pointer, 
These are for the 
results. They are null 
if the result is to be 
a quart, or point to a 
new segment of a rela- 
tion is to result. It 
is the responsibility 
of the RSM to initialize 


the new segment prmerly. 
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APPENDIX F 
CURRENT SYSTEM CODE 


Preface 


The following modules are included in PL/1 source form: 


mgr declare -- these are the declarations for the manager 

mro -- this is the portion of the manager which handles calls 
to union, intersect, difference, compose, project, cart_ 
prod, sort, successor _rel, convert_to _r, convert_toq, 
modify ent, get_ent, and clear ent. 

oro -- this is the portion of the manager which handles calls 
to new_relation, initiate relation, and squash array. 

ero -- this is the portion of the manager which handles calls 
to expand quart. 

mdo -- this is the portion of the manager which handles calls 
to get_refno, get_data, and successor data. 

odo -- this is the portion of the manager which handles calls 
to new _data type and kill data_type. 

GS_error -- the error handler (see Appendix G). 

GS_err_messages -- the error messages (see Appendix G). 

gsdb -- the system utility program (see Appendix H). 

dsm_astring -- this is the DSM which handles alphabetic 
strings to be placed in alphabetic order (see Appendix B). 

dsm_ integer -- this is the DSM for integers. 

dsm_chain -- this is the DSM for alphabetic strings to be 


placed in a non-alphabetic order. 
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dsm_table -- this is the DSM for alphabetic strings which 
are not in alphabetic order, and which are involved 
in frequent retrieval, and infrequent updating. 

rsm_wq -- this is the RSM which performs all operations 
Lexcept, Of Courses. Convert. 10-1): on, two quarts. 

rsm_q -- this is the RSM which handles quarts to be kept 
permanently. RSM Q calls RSM WQ to operate on the 
quarts, and only handles storage and retrieval of 
quarts to and from auxillary segments. 

trec == Ehis. 1s the algorithm to restructure a tree of a 
dsm astring data area. TREE produces.an optimal. tree, 
and a quart of new and old reference numbers to use to 


update all relations using that data type. 


-151= 


mgr_declare.incl.pll 05/20/70 
1116.4 edt Wed 


declare 1 parameter_structure based (param_ptr), 
arg no bit(17) , 

filler bit(2), 

display_if_8 bit(17), 

desc_no bit(17), 

multics_ junk bit (19), 

a_ptrs (100) pointer; /*pointers are compute 


NON NA DO PM 


d by formula*/ 
/*The following fs the technically correct version of the pa 
rameter structure. 
Note that the display pointer exists only if the di8 half 
word is 8. The actual 
method used is to compute an offset to use, since this is 
faster than this 
adjustable structure method. 
declare 1 arg_structure based, 
2 arg_no bit(17), 
2 filler bit(2), 
2 di8 bit(14), use of bit 14 has effect of 
dividing by 8 
filler bit(3), 
desc_no bit(17), 
filler bit(19), 
arg_ptrs (arg_no) pointer, 
display_ptr (di8&) pointer, 
desc_ptrs (desec_no) pointer; 
*/ 
declare 1 descriptor_structure based (desc_ptr), 
2 dt_code bit (15) , /*data type code - see 
MULTICS implementation of PL/1+*/ 
2 other_stuff bit(3), /*not used*/ 
2 string_size bit (18), 
2 low_bound fixed bin(35) , 
2 top_bound fixed bin (35); 
declare 1 quart based (gen_purpose_ptr), 
2 ID flxed bin(35) initial(0), /*zero !D mea 


NO PROB DY BO RO 


ns quart*/ 

qlength fixed bin(35), /*not used here*/ 

order fixed bin(35), /*not used here*/ 

cent(alloc_order refer (order)) char(32) , 

pent(alloc_order refer (order)) pointer, 
tent(alloc_length refer (qlength),alloc_orde 

r refer (order)) fixed bin(35); 


NRO RO POD PO 
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declare 1 arg_array_rsm hased (arg_ptr), 


upper_bound fixed bin(35) , 

opcode character. 61), 

qliptr (limit refer (upper_bound)) pointer, 
rl_ptr (limit refer (upper_bound)) pointer, 
q2_ptr (limit refer (upper_bound)) pointer, 
r2_ptr (limit refer (upper_bound)) pointer, 
equiv_ptr (limit refer (upper_bound)) pointe 


2 return_arg (limit refer (upper_bound)) point 


declare 1 arg_array_dsm based (arg_ptr), 


2 
2 
2 
2 
2 
2 
2 

r, 

er> 
2 
2 
2 
2 
2 
2 
2 
2 

Yr; 


declare 


high_bound fixed bin(17), 

column_index fixed bin(17) initial(1), 
opcode character(1), 

d_or_il_option character(1), 

e_option character(1), 

data_data_ptr pointer, 

d_or_q_ptr(limit refer (high_bound)) pointer 


return_arg (limit refer (high_bound)) pointe 


fixed_plate fixed bin(35) based (zen_purp 


ose_ptr); /*fixed bin template for quart. 1ID*/ 


declare 


oset bit(18) based (gen_purpose_ptr); /*Th 


is is for the area manf pulations/ 


declare 


label_plate char(16) based (sen_purpose_p 


tr); /*this is char(16) template for ID slot*/ 


declare 
eturnable_ptr); 

declare 
3 

declare 
e_ptr); 

declare 
rpose_ptr); 

declare 


pose_ptr); 
declare 
declare 


return_structure (limit) pointer based (r 


/*returned to the caller*/ 


option character (oplength) based (op_ptr 
based_nam character (4) based (gen_purpos 
rel_name character (lentty) based (gen_pu 
based_arg character(as_len) based (gen_pur 


p pointer based (sen_purpose_ptr); 
indexor (kk) pointer based (zen_purpose_p 


tr); /xthis acheives the kk th pointer*/ 


declare 
declare 
declare 
declare 
declare 
declare 


callname char(16) aligned; 

nam character(s) aligned; 
options character (3) aligned; 
ent character (32) aligned; 

op character(1) aligned; 

wdir character(168) aligned; 
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declare unique_chars_ entry external returns (char 
acter (15)); 
declare (error_table_$noarg,error_table_$segzknown, 
error_table_$name_not_found) 
fixed bin(17) external; 
declare (xfer,other_ptr,arg_ptr,desc_ptr,gen_purpo 
se_ptr,op_ptr,param_ptr,returnable_ptr) pointer; 


declare access_code fixed binary(5) initial(01011b 


oe 

declare (kk,kik,jj,mm,iii,limit,dlen,oplength,dose 
t,lwdir) fixed bin(17); 

declare (lentty,err_code,new_place,alloc_order,al] 
oc_length) fixed bin (17); 

declare (two_arg_sw,three_arg_sw,arg_array_sw,skip 
_3_sw) fixed bin(1) inftial (0b); 

declare (option_sw,nam_sw, ent_sw, ptr_sw,squash_sw, 
F_sw,S_sw) fixed bin(1) initial (0b); 

declare (as_len,op_bump) fixed bin(17); 


mra.pdl 05/20/70 1011.0 edt 


Sra: procedure returns (pointer): 
Zinclude mgr_declare; 


unz:union:sentry returns(pointer); 
op="U"; 
go to setupl; 
in:intersect: entry returns(pointer); 
op="I ". 
zo to setup]; 
di:difference: entry returns(pointer); 
op=")"; 
Z0 to setupl; 
epicart prod: entry returns Cpoloter); 
opal! Xxs 
ro to setupl; 
so:sort: entry returns(polnter); 
op="5'"s 
zo to setupl; 
sr:successor_rel: entry returns(pointer); 
op="pi'; 
go to setupl; 
cr:convert_to_r: entry returns(pointer); 
op="R"5 
go to setupl; 
cq:convert_to_q: entry returns(pointer); 
op="Q"s 
zo to setupl; 
co:compose: entry returns(pointer); 
op="C"; 
go to setupl; 
me:modify_ent: entry returns(pointer); 
ops"; 
go to setupl; 
ze:zet_ent: entry returns(pointer); 
opstetts 
zo to setupl; 
ce:clear_ent: entry returns({pointer); 
op="Z"5 
go to setupl; 
pr:project: entry returns(pointer); 
op="o"s 
go to setupl; 


Wer 


#T55* 


setupl: /*Here we do arument processinzg*/ 
call cu_$ars_list_ptr(param ptr); 
if display_if_8=8 then dosete#ars_norl: 
else doset=arg_no; 
if arg_no<2 then call GS_error$p(12,op,null,null); 


/*Error here is a null argument call in*/ 
if a_ptrs(1+doset )->dt_code=29 then do; 
/*xWe have first arg is array of pointers*/ 
ars_array_sw=lb; 
limitsa_ptrs(1+doset)->top_bound; 
if a_ptrs(1+doset)->low_bound“=1 then call GS_ 
error$p(14,op,a_ptrs(1),null); 
/*Error ee non one lower bounds*/ 
end; 
else if a _ptrs(1+doset)->dt_code=13 then do; 
arg _array_sw=0b; 
limit=1; 
end; 
else call GS_error$p(13,op,null,null):; 
/xError here is failure to have pointer or array of pointers 
for first arzuments*/ 


op_bump=a_ptrs(arg_no-1+oset )->dt_code; 
if op_bump=520]op_bump=522 then do; 
call cu_sarg_ptr(arg_no-1l,op_ptr,oplength,err_ 
code); 
If index(option, "F")7=#0|Index(option, "f")7=0 t 
hen F_sw=1b; 
if index(option, "S")7=O0|index(option,"s")7=0 t 
hen S_sw=lb; 
op_bump=1; 
end; 
else op_bump=0; 
if op="C" then kik=0; 
else kfik=1; 
if arsz_no-l-op_bump>3-kik then call GS_error$p(15, 
op,a_ptrs(1)->p,null); 
/*Error here is too many arszuments*/ 
do kik=2 to ar7_no-1l-op_bump; 
if limit=1 then do; 
if a_ptrs(kik+doset )->dt_code7"=13 then cal 
1} GS_error$p(16,0p,a_ptrs(1)->p, 
a_ptrs(2)->p); 
/*Error here is inconsistant upper bound*/ 
end; 
else do; 
other_ptr=a_ptrs(kik+doset); 
if other_ptr->dt_code“=29 then call GS_err 
#or$p(17,0p,a_ptrs(1)->p,null); 
/*Error here is inconsistant upper bound or typex/ 


-156- 


else if other_ptr->top_bound™=limit then c 
all GS_error$p(18,op, 
a_ptrs(1)->p,a_ptrs(kik)=->p); 
/*Error here is inconsistant upper bounds«/ 
else if other_ptr->low_bound7”=1 then call 
GS_errors$p(14,op,a_ptrs(1)->p,null); 
/*Error here is non one lower bounds/ 
end; 
if kik=2 then two_arg_sw=Ilb; 
else three_arg_sw=lb; 
end; 


/*Here we compare argument structures with those permiss 

ible by operations/ 

if two_arg_sw & (Cop="0"Jop="E"Jop="Z") then call 
GS_error$p(19,op,a_ptrs(1)->p,null)}; 
/*Error here is two arguments with cq,ge, or ce*/ 

if “two_arg_ sw & (op="H"[op="0"]}op="R") then call 
GS_errorsp(20,0p,a_ptrs(1)->p,null); 
/*Error here is omission of mandatory second arg in cr or me 
*/ 

if F_sw & (Cop="E"{op="M"lop="Z"') then F_sw=0b; 

if S_sw & Cop="N"fop="R"fops"E"fop="M"lops"Z"fop=" 
O") then S_sw=0b; 


/*Here allocate argument array structure and go to work 


allocate arg_array_rsm; 


setup2: do kk=l to limit; 
if op="C" then do; 
if three_arg_ sw then arg_array_rsm.equiv_p 


tr(kk)= 
a_ptrs(3)->indexor (kk); 
else arg_array_rsm.equiv_ptr(kk)=null; 
end; 
if “two_arg_swla_ptrs(2)->indexor(kk)=null- the 
n do; 


arg_array_rsm.q2_ptr(kk),are_array_rsm.r2_ 
ptr(kk)=null; 
if op="R" then go to err_20; 
end; 
else if a_ptrs(2)->indexor(kk)->fixed_plate=0 | 
op="M"|op="0" then do; 
arg_array_rsm.q2_ptr(kk)=a_ptrs(2)->indexo 
r(kk); 
arg _array_rsm.r2_ptr(kk)=null; 
if op="R" then do; 
err_20:; free ars_array_rsm; 
call GS_error$p(20,0p,a_ptrs(1)->p,a_p 
trs(2)- pn); 


Sede “15 7=- 


end; 
else do; 
arg_array_rsm.r2_ptr(kk)=a_ptrs(2)->indexo 
r(kk); 
arg_array_rsm.q2_ptr(kk)=null; 
if op="P" then do;/*frror handling$$$*/ 
free arm_array_rsm; 
call %S_error$p(21,op,a_ptrs(1)->index 
or(kk),r2_ptr(kk));3 
end; 
/*Error here is attempt to get successor of a relation*/ 
end; 


/*First operand is examined herex/ 
if a_ptrs(1)->indexor(kk)=null then do;/*Error 
handling$$$*/ 
free arg _array_rsm; 
call GS_error$p(22,op,null,null); 
end; 
/*Error here is a null first operand«/ 
if a_ptrs(1)->indexor(kk)->fixed_plate=9 then 


do; 
arg _array_rsm.ql_ptr(kk)=null; 
arg_array_rsm.rl_ptr(kk)=a_ptrs(1)->indexo 
r(kk); 
end; 
else do; 
ve arg_array_rsm.ql_ptr(kk)=a_ptrs(1)->indexo 
r(kk); 


arg _array_rsm.rl_ptr(kk)=null; 
end; 
end; 


/*Here we process callings name for most oaperations*/ 
setups: do kk=l to limit; 
if op="R" then gro to must_be_second; 
if ars_array_rsm.rl_optr(kk)“=null then do; 
if kk=l1 then callname=addrel(a_ptrs(1)->o, 
a_ptrs(1)->p->oset)->label_plate; 
else if addrel(a_ptrs(1)->indexor(kk),a_pt 
rs(1)->indexor(kk)->oset )->label_plate “= 
callname then do; 
/*Error handling$$S*/ 
free arg_array_rsm; 
call GS_error$p(23,op,a_ptrs(1)->p,a_p 
trs(1)->indexor(kk)); 
end; 
/*Error here is specification of inconsistant RSM names*/ 
end; 
else do: 
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if “two_arg_swlarg_array_rsm.r2_ptr(kk)=nu 
Tlfop="M'"fop="0" then do; 
if kk=1 then callname="rsm_wa"; 
else if calliname7="rsm_wq" then do; 
free arg_array_rsm; 
call GS_errorsp(24,op,a_ptrs(1)->p 
,a_ptrs(1)->indexor(kk)); 
end; 
/*Error here is inconsistant RSM names*/ 
end; 
else must_be_second:do; 
if kk=1 then callname=addrel(a_ptrs(2) 
->p,a_ptrs(2)->p->oset )->label_plate; 
else if addrel(a_ptrs(2)->dindexor(kk), 
a_ptrs(2)->indexor(kk)->oset)->label_plate™= 
callname then do; 
/*Error handling$$$*/ 
free arz_array_rsm; 
call GS_error$p(25,op,a_ptrs(2)->p 
,a_ptrs(2)->indexor(kk)); 
end; 
/*Error here is inconsistant RSM names*/ 
end; 
end; 
end; 


/*Where it is proper, space is obtained for the new resu 
It relation*/ 
setup6: if op="Q"fop="E"lop="M"[op="Z"" then go to setup7; 
do kk=1 to limit; 
arg_array_rsm.return_arg(kk)=null: 
if art_array_rsm.rl_ptr(kk)=null then go to no 
oes *R™ 


_new_r; 
call hes_$fs_search_get_wdir(addr(wdir), lwdir) 


. 
od 


call hes_$make_seg(wdir,'""','""', access _code,arg_ 


array_rsm. return_arg(kk),err_code); 
if err_code>0 then do;/*Error handling$$$*/ 
free arsz_array_rsm; 
call GS_error$p(26,op,a_ptrs(1)->indexor(k 
k),a_ptrs(2)->indexor(kk)); 


end; 
/*Error here is failure of make seg procedure*/ 


if F_sw & op7="R" then do; 
F_sw=0b; 
option_sw=lb; 
zo to no_name_needed; 
end; 
else do; 
call ioa_$nni("New relation created. Op jis 


“la. Relation 1 ts “p. Give new name...", 


$ 


oe) 


iain 


on gy 


aot 


oy 


ia 
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are array orsm.a? ntr(kk)7=null then 


quart; 


hestrelentry_seco(a_ ntrs(2)~> 


return structure; 
beats 


ry 


Po struc 


, 
t 


“y 


ure(mm)sare_array orsn,return_ 


. 
, 


=returnable str: 
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yo 


IF 
oro: procedure returns(pointer); 
%include mgr_declare; 


nrinew_relation: entry returns(pointer); 
call cu_targ_ptr(1,gen_purpose_ptr,lentty,err_code 


3 


13 
/*Error here is null relation names/ 
call cu_$arg_list_ptr(param_ptr); 
if display_if_8=8 then doset=arg_notl; 
else doset=arg_no; 
if argz_no~=3 then call GS_error$p(2,"N",null,null) 


if err_code>0 then call GS_error$p(1,"N",null,null 


c 
/*Error here is incorrect arszument specification for nr+*/ 
if a_otrs(2+doset)->dt_code“=13 then call “S_error 
$03, "N" null melt): 
/*Error here is non_pointer second argumetn for nr*/ 
limit=1; 
allocate arg_array_rsm; 
op="Nts 
if a_ptrs(2)->p=null then do;/*Error handling$$$*/ 


free ars_array_dsm; 
: call GS_error$p(4,op,null,null); 
end; 
/*Error here is failure to specify an r for the rsm namer/ 
cal }name=addrel (a_ptrs(2)->p,a_ptrs(2)->p->oset )-> 
label_plate; 
call hes_$fs_search_set_wdir(addr(vidir),lwdir); 
call hes_$make_seg(wdir,rel_name,rel_name,access_c 
ode,arg_array_rsm.return_arg(limit),err_code); 
if err_code>0 then do;/*Error handling$$$*/ 
free ars_array_rsn; 
4 call SS_errorsce(5,o0p,rel_name,nul1); 
end; 
/*Error here is fatlure in make segment procedure*/ 
zo tao setup7; 


ir:initiate_relation: entry returns(pointer); 

; call cu_$arz_ptr(1,gen_purpose_ptr,lentty,err_code 
if err_code>0 then call GS_error$p(6,"Z",null,nul1 

as 

/*Error here is null relation namex*/ 
<4 


imi eats 
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limit-1, 
allocate arg_array_rsm; 
ops"Z"s 
call hes_$fs_search_get_wdir(addr(wdir),lwdir); 
call hes_Sinitiate(wdir,rel_name,rel_name,0,0,arg_ 
array_rsm.rl_ptr(limit),err_code); 
if err_code>0 & err_code™=error_table_$segknown th 
en do;/*Error handling$s$ */ 
free arg_array_rsm; 
call GS_errorsc(7,op,rel_name,null); 
end; 
/*Error here its failure to initiate relation specified in ir 
operation*/ 
callname=addrel(arg_array_rsm.rl_ptr(limit),arg_ar 
ray_rsm.rl_ptr(limit)->oset)->label_plate; 
zo to setup7; 


sa:squash_array: entry returns(pointer); 
call cu_$arg_list_ptr(param_ptr); 
if display_'f_8=8 then doset=arg_notrl; 
else doset#arg_no; 
if a_ptrs(1l+doset)->dt_code"=29 then call GS_error 
$p(8,"A",null,null); 
/*Error here is non array of pointers for first argument*/ 
limit=l; 
allocate arg_array_rsm; 
limit=a_ptrs(1+doset )->top_bound; 
if a_ptrs(1l+doset)->low_bound™=1 then do; 
free arg_array_rsm; 
call GS_error$p(9,"A",a_ptrs(1)->p,null); 
/*Error here is non one lowver hbound+/ 
end; 
alloc_length=0; 
alloc_order=a_ptrs(1)->p->order; 
do kk=1 to limit; 
alloc_length=alloc_length+a_pty+s(1)->indexor(k 
k)->qlength; 
do jj=l to alloc_order while (kk>1); 
if a_ptrs(1)->indexor(kk)->cent(jj)"=a_ptr 
s(1)->p->cent(jj) then do;/*Error handling$%$*/ 
free arvt_array_rsm; 
call GS_error$p(10," ",a_ptrs(1)->p,a_ 
ptrs(1)->indexor(kk)); 
end; 
/*Error here is inconsistant cent entries*/ 
end; 
end; 
allocate quart set (gen_purpose_ptr); 
kik=1; 
arg_array_rsm.ql_ptr(kik)=gen_purpose_ptr; 
squash_sw=1b; 
new_place=0; 
do kk=1 to limit; 
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@ro: procedure returns(pointer); 


Sinclude mer_declare; 


eq:expand_quart: entry returns (pointer); 
call cu_sarg_list_ptr(param_ptr); 
if display_if_8=8 then doset=arg_notl; 
else doset=arg_no; 
if a_ptrs(1+doset)->dt_code "=13 then call “SS_error 
$p(11," ",null,null); 
/*Error here is non pointer arsument*/ 
limit=za_ptrs(1)->p->qlength; 
allocate return_structure; 
alloc_order=a_ptrs(1)->p->order; 
alloc_length=1; 
do kk=1 to limit; 
allocate quart set (return_structure(kk)); 
do jj=1 to alloc_order; 
return_structure(kk)->cent (jj )=a_ptrs(1)-> 
p->cent (jj); 
return_structure(kk)->pent(jj)=a_ptrs(1)-> 
p->pent(jj); 
return_structure(kk)->tent(1,jj)=a_ptrs(1) 
->p->tent(kk, jj); 
end; 
end; 
free a_ptrs(1)->p->aquart: 
a_ptrsCare_no)->p=returnahle_ptr; 
end; 
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indo: procedure returns(pointer); 
include mer_declare; 


gr:zet_refno: entry returns(pointer); 
Pa } Ww, 
op="'R"; 
so to setupld; 
sd:successor_data: entry returns(pointer); 
—I! fu, 
op="S"; 
zo to setupld; 
ed:get_data: entry returns(pointer); 
op="D'"; 
go to setupld; 


/xHere check the general structure of arguments*/ 
setupl0O: cali cu_Sarg_litst_ptr(€param_ptr); 
if cisplay_if_8=8 then doset=arg_notl; 
else dosetfarg_no; 
if arz_na¢? then go to err_368; 
if a_otrs(l+doset)->dt_code=#=13 then limit=1; 
else if a_ptrs(l+doset)->dt_code=?9 then do; 
limit=a_ptrs(l+doset)->top_bound; 
if a_ptrs(1l+doset)->low_hound7=1 then call “S_ 
error$p(37,0p,null,null); 
/*xError ners Le non zero lower hound on input array*/ 
end; 
else err_38: call GS_errorsSp(38,op,null,null); 
/*Error here is non pointer first argument+/ 
if ars_no>6 then call GS_error$p(39,0p,a_ptrs(1)-> 
p,null); 
/*Error here is illegal number of arguments*/ 


/*Here do the interpretation of the arczuments*/ 
if op="R" then do; 


if a_ptrs(2+doset)->dt_code=13 then ptr_sw=lb; 


if argz_no<& then go to no_further_check; 
if a_ptrs(3+doset)->dt_code=13 then do; 
if limit=l then skip_3_sw=l1b; 
else call S_error$p(40,op,a_ptrs(1)->p,a_ 
otrs(3)->p); 
/*Error here is inconsistant upper bounds on optional R argu 
ment*/ 
end; 
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else if a_ptrs(3+doset)->dt_code=29 then do; 
if limit=a_ptrs(3+doset)->top_bound then s 
kip_3_sw=1b; 
else call GS_error$p(40,op,a_ptrs(1)->p,a_ 
ptrs(3)->p); 
/*Error here is inconsistant upper bounds on optional R argu 
ment*/ 
end; 
no_further_check:if “ptr_sw then do; 
call cu_$arg_ptr(2,gen_purpose_ptr,as_len, 
err_code); 
if err_code>0 then call GS_error$p(41,0p,a 
_ptrs(1)->p,null); 
/*Error here is incorrect format for NAM field+*/ 
if as_len ™=4 then call GS_error$c(42,op,ba 
sed_arg,a_ptrs(1l)->p); 
nam=based_arg; 
nam_sw=l1b; 


end; 
end; 
else do; 
call cu_$arg_ptr(2,gen_purpose_ptr,as_len,err_ 
code); 
if err_code=error_table_Snoarg then go to no_n. 
ore: 


else if err_code>0 then call GS_error$p(43,op, 

a_ptrs(1)->p,null); 
/*Error here is format error in argument 2*/ 
if as_len=4 then do; 

nam_sw=l1b; 

nam=based_arg; 
end; 
else go to read_arg; 
end; 


iii=3; 
next_one: if skip_3_sw then 


f fii=3 then iii=4; 
call cu_$arg_ptr(ifi 


i 
ii,gen_purpose_ptr,as_len,err_co 


de); 
if err_code=error_table_$noarz then go to no_more; 


else if err_code>0 then call GS_error$p(43,0p,a_pt 


rs(1)->p,null); 
/*Error here is format error in arzument ifi*/ 
read_arg: if as_len<4 then do; 
oplensth=as_len; 
option_sw=lb; 
options=based_arg; 
end; 
else if as_len<33 then do; 
ent_sw=l1b; 
ent=based_arg; 
end; 
else call GS_errorsc(4h,op,based_arg,a_ptrs(1)->p) 
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/*Error here is argument of string size greater than 32*/ 
if iii=S then go to no_more; 
else ifitzsiii+l; 
sO to next_one; 


/*Here allocate the proper size arsument array*/ 
no_more: if option_sw & (index(Coptions, "E")7=09]index(option 
s,"e'")™=0) then do; 

squash_sw=l1b; 
if limit>1 then call GS_error$p(1l,op,a_ptrs(1 
)->p,null); 
/*Error here is feeding array to conceptual expand_quart ope 
ration*/ 
else limit=a_ptrs(1)->p->qlength; 
allocate arg_array_dsm; 
limit=l1; 
end; 
else allocate arg_array_dsm; 


/*Here set opcode and options slots*/ 
arp__array_dsm.opcode=op; 
/* Here scan the options*/ 
if option_sw then do; 
arg_array_dsm.d_or_i_option=" "; 
if (index(options,"D")7=0|index(options, "d")7s 
0) then 
arg _array_dsm.d_or_i_option="D"; 
if op="R" & Cindex(options, "1'")7=0]|index(loptio 
ns, "i'")7=0) then 
ars_array_dsm.d_or_i_option="I"; 
if squash_sw then ars_array_dsm.e_option="E"; 
else arz_array_dsm.e_option=" "'; 
do kik=1 to 3; 
om=index("123456789",substr(options,kik,1) 


if mm7=0 then do; 
column_index=mm; 
go to stop_col; 
end; 
end; 
stop_col: 
end; 
else arg_array_dsm.d_or_i_option,arg_array_dsm.e_o 


ption=" '"; 


/*Here set the return arg slot with given pointers 


, if needed«/ 
do kk=1 to limit; 


if skip_3_sw then arg_array_dsm.return_arg(kk) 
=a _ptrs(3)->indexor(kk); 


-168- 
else ars_array_dsm.return_are(kk)=null; 
end; 


/*Here do consistancy checking on the pents or cen 
ts*/ . 
if “nam_sw & “ptr_sw then do; 
iif i=0; 
do kk=1 to limit; 
if a_ptrs(1)->indexor(kk)->quart.pent(colu 
mn_index)™=null then do; 
if iii=0 then ifti=kk; 
else if a_ptrs(1)->indexor(kk)->quart. 
pent (column_index)7“= 
a_ptrs(1)->indexor(iii)->quart.pen 
t(column_index) then do; 
free arg_array_dsm; 
call GS_error$p(45,op,a_ptrs(1)->i 
ndexor(kk),a_ptrs(1)->indexor(iii)); 
/*Error here is inconsistant data type by non null pents*/ 
end; 
end; 
if substr(a_ptrs(1)->indexor(kk)->cent(col 
umn_index),1,4)7= 
substr(a_ptrs(1)->p->cent (column_index 
),1,4) then do; 
free arz_array_dsm; 
call GS_error$cce(4&6,op,a_ptrs(1)->p->o¢c 
ent (column_index),a_ptrs(1)->indexor(kk)-> 
cent (column_index)); 
end; 
/*Error here is inconsistant data types by cent name*/ 
end; 
end; 


/*Here fill in first arguments*/ 
do kk=1 to limit; 
arg_array_dsm.d_or_q_ptr(kk)=a_ptrs(1)->indexo 


r(kk); 
end; 
/*xHere construct the ddptr*/ 
if ptr_esw then do; 
arg _array_dsm.data_data_ptr=a_potrs(2)->p; 
end; 
else if “nam usw then do; 
if iii=0 then do; 
iii=l; 
13 call hes_$fs_search_set_wdir (addr (wdir),1w 
air); 


call hes_Sinitiate(wdir,substr(a_ptrs(1)-> 
p->quart.cent(column index).1,4), 
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substr(a_ptrs(1)->p->quart.cent (column_i 
ndex),1,4),0,0,a_ptrs(1)->p->quart. pent (column_index), 
err_code); 
if err_code=error_table_Ssegknown then do; 
end; 


Z$$se*/ 


else if err_code>0 then do;/*Error handlin 


free ars_array_dsm; 
call GS_error$c(47,op,a_ptrs(1)->p->ce 
nt(column_index),a_ptrs(1)->p); 
end; 
/*Error here is failure in get seg ptr or initiate procedure 
* / 


end; 
arg_array_dsm.data_data_ptr=a_ptrs(1)->indexor 
(iii )->quart.pent (column_index); 
end; 
else do; 


call hes_$fs_search_get_wdir(addr(wdir),1lwdir) 

. call hes_$initiate(wdir,substr(nam,1,4),substr 
(nam, 1,4), 

0,0,arc%_array_‘sm.data_data_ptr,err_code); 


if err_code=error_table_Ssegknown then do; end 


else if err_code>0 then do;/*Error handling$$$ 
" free arg_array_dsm; 
call GS_error$c(48,op,nam,a_ptrs(1)->p); 
/*Error here aes in get seg ptr or intitiate procedur 
7 end, 


/*Here set callname and issue call to dsm*/ 
callname=addrel (data_data_ptr,data_data_ptr->oset) 
->label_plate; 
as call hes_Smake_ptr("",callname,callname,xfer,err_c 
ode); 
if err_code>0 then do; 
Free arg _array_dsin; 
call GS_error$c(49,op,callname,null); 
end; 
call cu_$ptr_call(xfer,arg_ptr); 


/*dere do post call processing like filling in ret 
urn args and ents/ 
do kk=1 to limit: 
if Cop="S"lop="R") & ent_sw then do; 
arg_array_dsm.return_arg(kk)->quart.cent(c 
olumn_index)=ent; 


“3 
ras 
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odo: procedure returns (pointer); 


“include mgr_declare; 


nd:new_data_type: entry returns(pointer); 
call cu_$arg_list_ptr(param_ptr); 
if display_if_8=8 then doset=arg_notl; 
else doset=arg_no; 
call cu_$arg_ptr(2,gen_purpose_ptr,lentty,err_code 
ds 
if err_code>0 then call GS_errorsp(28,"N",null,nul 
1); 
else callname=rel_name; 
/*Error here is non label second arg*/ 
limit=1; 
allocate arg_array_dsm; 
do; 
call cu_Sarg_ptr(1,gen_purpose_ptr,dlen,err_co 
de); 
if err_code>0 then do;/*Error handling$$$*/ 
free arg_array_dsm; 
call GS_error$p(29,"N",null,null); 
end; 
/*Error here is incorrect first argument*/ 
if dlen“=4 then do;/*Error handling$$$*/ 
free arg_array_dsm; 
call GS_error$c(30,"N", based_nam,null); 
end; 
/*Error here is incorrect length for data type name*/ 
call hes_$fs_search_get_wdir(addr(wdir),]lwdir) 
a 
call hes_$make_seg(wdir,based_nam,based_nam,ac 
cess_code,arg_array_dsm.data_data_ptr,err_code); 
if err_code>d then do;/*Error handling$$$*/ 
free arg_array_dsm; 
call GS_error$c(31,"N",based_nam,null); 
end; 
/xError here is failure in make seg procedure*/ 
arg_array_dsm.opcode="N"; 
end; 
arg_array_dsm.high_bound=limit; 
call hes_$make_ptr("",callname,calIname,xfer,err_c 


arg -accay.tim.d 06 _togten, 
AdQ-aray - Seq, C-oghon:" "> 


ode); 
if err_code>0 then do; 
free ars_array_dsm; 
call GSS error$c(49,arg_array_dsm.opcode,callna 
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me,null); 

/xError here is illegal callnamer/ 
end; 
call cu_$ptr_call(xfer,arg_ ptr); 
a ntreCare_no)->pedata_data_ptr; 
return; 


kd:kill_data_type: entry returns(pointer); 
limit=1; 
call cu_Sarg_list_ptr(param_ptr); 
if display_if_8=8 then doset=arg_no+l; 
else doset=arg_no; 
if a_ptrs(1+doset)->dt_code=520|a_ptrs(l+doset)->¢4 
t_code=522 then do; 
call cu_$arg_ptr(1,gen_purpose_ptr,lentty,err_ 
code); 
if err_code=error_table_$noarg then call GS_er 
ror$p(32,"K",null,null); 
else if err_code=0 then do; 
if lentty“=4 then call GS_error$c(33,"K",r 
el_name,null); 
call hes_Sfs_search_get_wdir(addr(wdir),1w 
dir); 
call hes_$delentry_file(wdir,based_nam,err 
_code); 
if err_code>) then call GS_errors$ec(34,"K", 
based_nam,nul1); 
/xError here is failure in initiate or in mget seg ptr*/ 
end; 
end; 
else if a_ptrs(l+doset)->dt_code=13 then do; 
if a_ptrs(1)->p->quart.pent(limit)=null then d 
Oo; 
call hes_3fs_search_zet_wdir(addr(wdir),1w 
dir); 
call hes_$initiate(wdir,substr(a_ptrs(1)=-> 
p->quart.cent(limit),1,4), 
substr(a_ptrs(1)->p->quart.cent(limit) 
,1,4),0,0,gen_purpose_ptr,err_code); 
if err_code=error_table_%segknown then do; 
end; 
else if err_code>0 then call GS_error$c(35 
YK", a_ptrs(1)->p->cent(limit),a_ptrs(1)->p); 
/*Error here is failure in initiate or in get seg ptrx«/ 
end; 
else pen_purpose_ptr=a_ptrs(1)->p->quart.pent ( 
limit); 
; call hes_$delentry_ses(gen_purpose_ptr,err_cod 
€); 
if err_code>0 then call GS_error$p(36,"K",gen_ 
purpose_ptr,null); 
/*Error here is failure in delete seg procedurex/ 
end; 


i 


ue 
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GS_error: procedure; 
declare (p,pr) entry (fixed bin(17),char(1),pointe 


r,pointer); 
declare (c,cr) entry (fixed bin(17),char(1),char(* 
),pointer); 
declare (cc,ccr) entry (fixed bin(17),char(1),char 
(*),char(*)); 
declare code fixed bin(17); 
declare op char(1); 
declare (pl,p2) pointer; 
declare (cl,c2) char(*); 
declare err_code fixed hin(17); 
declare puse pointer; 
declare pi_label label static; 
declare «S_error$pi entry external; 
declare buffer char(120) initial(" "); 
declare num_items fixed bin(35) initial(120); 
declare ascode char(12); 
declare (cond_flag,p_sw,r_sw,c_sw,cc_sw) fixed bin 
(1) initial(0b); 
declare 1 quart based (quart_ptr), 
1D fixed bin(35), 
qlength fixed bin(35), 
order fixed bin(35), 
cent(l1 refer (order)) char(32), 
pent(1 refer (order)) pointer, 
tent(l refer (qlength),1 refer (order)) fixe 


NO BD PO AO DO PO 


d bin(35); 

pr: entry (code,op,pl,p2); 
r_sw=lb; 

p: entry (code,op,pl,p2); 
p_sw=l1b; 
zo to message; 

cr: entry (code,op,cl,pl); 
r_sw=lb; 

Cc: entry(code,op,cl,pl); 
c_sw=Ih; 
zo to message; 

cer: entry (code,op,cl,c2); 
r_sw=lh; 

cc: entry(code,op,cl,c2); 
cc_sw=lb; 

message: call foa_("GS: Error “5d Internal opcode “a",code, 

op); 


if cc_sw then call joa_(" Name 1: “a Name 2: 7 
a",cl,c2); 
else if c_sw then do; 
call ioa_$nni(" Name 1: “a ",cl); 
if pl7=null then call ioa_(" Pointer 1: “p",pl 


“_ 
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3 : 
else call fioa_(" "); 


end; 
if p_sw then do; 
if pl7=null then call foa_$nnl(" Pointer 1: 
=p | pls 
if p2~=null then call jioa_Snni(" Pointer 2: 
py 2Ns 
if pl7=null|p27=null then call ioa_(" "); 
end; 
call cv_bin_(code,ascode,10); 
call joa_$nnli(" sb 
call print("GS_err_messages",ascode,ascode); 
new_try: if r_osw then call foa_$nni(" Type procedure na 
me, return, or quit...'"); 
else call ioa_$nni(" Type procedure name, or qu 
ites 0G 
call ios_$read_ptr (addr (buffer),num_items,kk); 
if rosw & substr(buffer,1,kk-1)="return" then retu 
rn; 


if substr(buffer,1,kk-1)="quit" then call signal_( 
"GOLD_STAR"); 

call hes_$make_ptr("", substr(buffer,1,kk-1),substr 
(buffer,1,kk-1),puse,err_code); 

if err_code>0 then call ioa_(" No such procedur 
e can be found!"); 

else call cu_$ptr_call(puse); 

go to new_try; 

end; 


WMWrw NHN 
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Argument for nr operation not found, 

nr operation does not have two arsuments plus return argumen 
t(non_functional invocation is illegal). 

Second argument of nr operation is not a pointer. 

Second argument of nr operation is a null pointer. 

Make segment procedure in nr operation failed - name provide 
d is attempted relation name. 

Arzument not found for ir operation. 

Initiate procedure failed for ir operation - name provided i 
s attempted name. 

Argument for sa operation jis not an array of pointers. 

Low bound of argument(pointer 1) fis not one. 

CENT inconsistancy found between elements of array of pointe 
rs in sa operation(pointer 1 and 2). 

Argument in eq operation must be pointer. 

Too few arszuments-must be at least one plus return for funct 
ional invocation, 

First argument must be pointer or array of pointers. 

Low bound of first arszument(pointer 1) must be one. 

Too many arguments(pointer 1 is first one). 

All arguments must be pointers if first one is(pointer 1). 
All arguments must be arrays of pointers if first one is(poi 
nter 1). 

Upper bound of input argument arrays(pointers 1 and 2) are n 
ot the same. 

Operation cannot have more than one argument(nointer 1). 
Operation must have more than one argument(pointer 1). 
Successor cannot have relation as second argument(arg l=poin 
ter 1, ars 2=pointer 2). 

First operand cannot be null. 

First argument is array of relation pointers calling for inc 
onsistant RSMCpointers 1 and 2). 

Second argument is an illegal array of quart and relation po 
inters(pointers 1 and 2). 

Second argument is array of relation pointers calling for in 
consistant RSM(pointers 1 and 2). 

Make segment procedure failed - arzuments one and two are po 
inters 1 and 2. 

Change name procedure has failed on segment of pointer 1. 
l[llegal second argument for nd operation. 

Illegal first arsument for nd operation. 

Data type name (Name 1) in nd operation is not four characte 
rs. 

Make segment procedure has failed during nd operation(name a 
ttempted was Name 1). 

‘No argument given for kd operation. 

Type(Name 1) indicated in kd operation not four characters. 
Delete segment procedure failed during kd operation(name att 


a ioe 


39 

1000verlapping CENT in cp operation hetween Pointer 1 and ?. Re 
turn yeilds null pointer. 

1010rders of quarts (pointers 1 and 2) are not equal. "eturn ye 
ilds null result, 

1O2CENT of guarts (pointers 1 and 2) do not overlap. Ffeturn yei 
Ids null result. 

1034idth of equivalence vector(Pointer ?) must be equal to orde 
r of quart(Pointer 1). 
104 
105 


va Gf 


<s>ogsdb.pll 05/20/70 1053.3 edt 
Wed 
asdb: procedure; 
declare 1 dsm hased (Cinptr), 
2 dtop fixed bin(17), 
2 cindex fixed bin(17), 
2 dop char(1), 
2 di char(1), 
2 eopt char(1), 
2 ddptr pointer, 
2 dqaptr (1 refer (dtop)) pointer, 
2 dretptr (1 refer (dtop)) pointer; 
declare 1 rsm based (inptr), 
2 rtop fixed bin(35), 
2 rop char(1), 
2 ql (1 refer (rtop)) pointer, 
2 rl (1 refer (rtop)) pointer, 
2 q2 (1 refer (rtop)) pointer, 
2 r2 (1 refer (rtop)) pointer, 
2 ep (1 refer (rtop)) pointer, 
2 rretptr (1 refer (rtop)) pointer; 
declare 1 quart based (inptr), 
2 1D fixed bin(35), 
2 qlen fixed bin(35), 
2 qorder fixed bin(35), 
2 cent (1 refer (qorder)) char(32), 
2 pent (1 refer (qorder)) pointer, 
2 tent (1 refer (qlen),1 refer (qorder) fixed 
bin(35); 
declare 1 entvector based (inptr), 
2 width fixed bin(35), 
2 ents (1 refer (width)) char(32); 
declare gsdb$pi entry external; 
declare (d,r,q,e) entry (pointer) external; 
declare call_sw fixed bin (1) initial(0b); 
declare pi_lahel label static; 
declare op char(4) initial(" de 
declare buffer char(132); 
declare (baseptr,addrel,min,substr,index) builtin; 
declare cv_oct_ entry external returns (fixed bin( 
35)); 
declare woffset fixed bin(35) initial(0); 
declare wptr pointer initial (null); 
declare (inptr,aptr) pointer; 
declare (mn,kk,ii,orplace,endplace) fixed bin(17); 
call ioa_("ASK!I"); 
call_sw=lb; 
pi_label=read; 


read: 


O; 


start_no: 


); 
offset_onl 


end_found: 


no_offset: 


e: 
labset: 


output: 
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call ios_Sread_ptr(addr (buffer),132,kk); 
op=substr(buffer,1,1); 
if op="." then return; 
if op7="d" & opT="r" & opT="q!" & opt="e" then do; 
call ftoa_("?"); 
=o to read; 
end; 
do mm=2 to kk-1; 
if substr(buffer,mm,1)7=" " then go to start_n 


end; 
go to no_offset; 
orplace=index(buffer,"|"); 


if orplace=0 then do; 

orplace=mm-1; 

go to offset_only; 
end; 
wptr=baseptr(cv_oct_(substr(buffer,mm,orplace-mm) ) 


y: do fizorplacet+l to kk-1; 
if substr(buffer,ii,1)=" " then do; 
endplace=ii; 
go to end_found; 
end; 
end; 
endplace=kk-1; 
mmnzendplace+l-orplace; 
if mm=0 then go to no_offset; 
woffset=cv_oct_(substr(buffer,orplace+1,mm)); 
inptrzaddrel (wptr,woffset); 
so to output; 


entry(aptr); 

op="d"; 

ro to labset;3 

entry(aptr); 

op="r'ts 

go to labset; 

entry(aptr); 

op="q"!s 

zo to labset; 

entry(aptr); 

ops"el's 

pi_label =back; 

inptr=aptr; 

if inptr=null then do; 
call foa_("NULL!"); 
go to done; 

end; 

call condition_("program_interrupt",gsdb$pi ); 

call foa_("AT “p",inptr); 

if op="q" then do; 
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do ii#1 to qorder; 
call fioa_(""16a “p",cent(ii),pent(ii)); 
end; 
do ii=l to qlen; 
do mm=1 to qorder; 
call ioa_$nni("78d ",tentCii,mm)); 
end; 
call foa_(" "); 
end; 
end; 
else if op="r"' then do; 
call ftoa_("Bound 73d Op “la",rtop,rop); 
call ioa_("Q1 Rl 12 R2 
EP RET"); 
do Til to rtop; 
call ioa_(""p “p “p 7p 7p “p", alii), rl ii 
),q2(ii),r2Cii),eplil),rretptr(ii)); 
end; 
end; 
else if op="d" then do; 
call foa_("Bound “3d Op “la OD! option “la 
E option “la C option “ld DDptr “p", 
dtop,dop,di,eopt,cindex,ddptr); 
call foa_("D or Q RETURN"); 
do fi=1l to dtop; 
call ioa_(""p “p",dqptr(ii),dretptr(ii)); 
end; 
end; 
else do if=l to width; 
call foa(""l6a",ents(ii)); 


end; 

done: if call_sw then go to read; 
else 

back: return; 

pi: entry; 


zo to pi_label; 
end; 


Mon 
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dsm_astrins.nll 95/01/70 


dsm_astring: procedure (dsm_arcs_ptr); 


cel data_ses area (arca_tsize) based (ser_ptr); 


col 


eron| 


dc] 


dc] 


dc] 


9 
cod 
9 
& 
. 
= 
9 
a 
io 
“ 


), 


cent char (32), 
pent ptr, 
tent fixed bin (35); 


1 quart_proper hased (uart ptr), 


aie fixed hin (35), 

qlength fixed hin (35), 

aorder fixed bin (35), 

aeent (qorder? char (32), 

apent (qorder) atr, 

qatent (qlencth,qorder) fixed hin (35); 


hOB BO Bo PO RO 


1 mt quart static, 


Z 


Z 
2 
2 
2 


mtid fixed hin (35) fnittal (9), 
mtlength fixed bin (35) fnittal (9), 
mtorder fixed sin (35) initial (1), 
mtcent char (32), 

mtpent otr; 


1 dsm_arss based (dsm_ares_ptr), 


BO RO PPO AO AD DO DO 


upper_bound fixed hinary (17), 
ci fixed btn (17), 

op char (1), 

di char (1), 

e chor (1), 

ddptr otr, 

d_or_q_otr (unpper_bound) ptr, 
return_otr (Cunper_hound) ptr; 


1 type based (type_ptr), 


NON BO PO NO PO NO 


dsmnamne char (16), 

data_type char (32), 

num_free_cells Fixe! Sin (35), 
numlentries fixed bin (35), 

max_leneth fixed hin (35), 

firstlentry offset (data_ser), 
successor_chain_head offset (data_ser); 


tem based (iptr), -183- 


del 1 i 

2 Iptr offset (data_se), 

2 rptr offset (data _se~), 

2 suce offset (data_sen), 

2 flag fixed binary (35), 

2 refno fixed bin (35), 

2 strins_structure, 
3 string_leneth Fixed hinery (35), 
3 string character (max_leneth); 


del 1 arrea_ser based (ser_ptr), 

2 first_off offset (data_se7), 
2 curr_len offset (data_ser), 
2 next_off offset (data_ser); 


~) 


del 1 pseudo_strinr_array hased (str_ptr), 
2 pseudo_lenrth fixer Sinary (35), 
2 inputlor_return_ string char (mlen_int); 


acl (ptr,new_ptr,succ_ptr,type_ptr,new_sec_ptr, 
quart_ptr,see_ptr,iptr,str_ptr) ptr static; 


del dsm_aress_ ptr otr; 
cel (area_size,i,ii,fourd,mlen_int diff, ciffer,turn,oresen 
tec_loop_refno, stored_loonp_refno, 


iiji,tk,t,erech) fixe sinary (35) static; 


del (max_depth_of_tree initial (34). left inftial (10), rich 
t initial (2%) fixed binary (35) static; 


del return_label label Cinsert_return, datum_return, refno_r 


eturn,successor_return, 
cdalote_by_refno_return, dealete_by_d 


atum_return,r_,d_,s_,i_,rd,dd); 
del dbhbd_lahbel (-1:1) label (hertneidsm_astrine) static; 
acl dbr_ label (-1:1) label (berin_dss_astrins) static; 
cel succ_label (-1:1) lahel (Cherin_ds~_astrinc) static; 


del insert label (1:1) label (herzin_dsm_astrins) static; 


del ins_comp_lahel (-1:0) label (berin_dsm_astring) static 


del enane char (32), dirname char (160) static; 


del (presented_lcop_strins, stored_lonn_strint) character ( 
168) varyinrs static; 


cel (exp,cori,oncode) char (1) varyine static; 
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acl tree_restructure entry Cpointer,nointer,nointer), 
(area_Sredef,area_) entry (fixe binary (17),pointer) 


“Ne 


del (null,nullo, substr,divide, atdrel,rin,adir) builtin; 
del (off,curr,next,code) fixed hinary (35) static; 


del (glich,last_left,last_urizht) offset (data_se™) static; 


del (cd lab_sw, dbr_lab_sw,tns_lab_sw, suce_lab_sw) fixed bh 
in (35) static initial (9); 


[RRR KK KK RRR ERK KEK RK RE KKK EK EK KR ERE EKER KRKRAKKEK KEK KK KKK KK 
RRR KEKE REAR AK KEE KR AK RK KER KEKE RK RK RE KK KKK KKK KEE / 


‘cecsin_dsm_astring: 


expsdsm_arnas.o; 
coritecdssaras.ci; 
opcodesdsm_arcs.on; 

sem ptredsn_ares.cddptr; 
type_ptr=first_off; 


if opcode="B" then /* jnnut fs refnos */ 
if cori=" " then co to zet_datun; 
else if dori="D" then co to delete_by_refno; 
else go to op_error; 


else Tf opcodes!9" then /* data strines are ftnput */ 
if dori=" " than so to «et_refno; 
else if dori ="9" then co to deleate_by_datum; 
else if doris"I" then eo to Insart; 


else =o to on_error; 
else if ancodes"S" than 


if dori =" " then eo to suceessor; 
else goa to op_error; 


else if apcodest!'| than 
if (dori=" " * exps" ") then co to new_data_type; 
else fo to op_error; 


else fo to op_error; 


[RK KARR KEKE EKRKEKKREKEKAR RAK KR RK KAR RK / 
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new_data_type: 
do ji = 1 ta upner_hound; 
call area_(1%2%,see_ptr); 
call hes_$fs_act_nath_nann(ser_ptr,dirnane, rec’ 
,ename,code); 
allocate tyne set (tynoe_ptr) in (data_see); 
num_entries=9; 
num_free_cells=20; 
call foa_("what fs max leneth for character stri 
nes for “a>“a 2?7/",substr(dirnans, 1,¢rech),enane); 
call read_list_(erech); 
max_lensth=rrech; 
successor_chain_heaasenullo; 
data_type=enamne; 
dsm_name="dsm_astrine"; 
first_lentry=nullo; 
end; 
return; 


[RRR RAK RK RRR RR RR ROR tok a tok kok ee kw / 


gpet_datum: 
do ti = 1 to upper_bound; 
return_laheledatun return; 
go to refno_prelocuc; 
datum_return: 
if found=] * ntr->flarsl then co; 
return_label=d_; 
so to string alloc; 
cde 2: 
pseudo_leneth=ptr-ostrinz_lencth; 
input_or_return_strincv=suhbstr(ptr->ostrine,],otr- 
>string_lenrth); 
end; 
else do; 
dsm_ares.return_ptr( ti) =addr(mt_quart); 
mtcentsdata_typn; 
mtpent=ser_optr; 
end; 
end; 
return; 


[RRR RRR RR RIOR Rk dK kok tok tok kee / 
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eet_refno: 
do if = 1 to unper_boun’t; 
returr_lahel=refno_return; 
so to datunm_prolocur; 
refnro_return: 
if found=1 % otr->flar=l then do; 
return_lahel=r_; 
£0 to quart_alloc; 


Fs 
tent=ptr->refno; 
end; 

else to; 


dsm_ares,return_ptr(C ii) sadder (mt_quart); 
ntcent=data_tyre; 
mtpent=ser_ptr; 
enc; 
ena; 
return; 


[RRR RRR KK RRR ERK REEMA EERE RE KER / 


successor: 
if succ_lab usw=3 then do; 
succ_lah_sw=l; 
succ_lahel (-1)=suse_1t_3 
succe_lahel (9) =suce_eq_0 
succ_lahel (1) =sucec_st_6; 
end; 
do if = 1 to upper_bannt; 
return_labelss_; 
go to quart_alloc; 
S.1% 
suce_ptr=quart_ptr; 
returt label ssuceessor_return; 
so to refno_prolocue; 
successor_return: 
mO to succ_lahel( fount); 


suce_¢cq_): 
if turnstefr ther do; 
if lastlricehtenulian then do; 
ptr=successor_ chain head; 
if ptr->flac=1] than ‘lo; 
succ_ptr->tonteptr- refine; 
GO to successor_end; 
end; 
else fo to suce_et_0; 
end; 
else ptr=last_lrischt; 
end; 
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ins_comp_lehel(- 1) =ins_es inl t_3; 
ins _comp_label (9) =ins_catn_ee_0; 
end; 
do Fi = PT toa umner_bour’; 
return_lobeleirserturetirn; 
20. LO Aatum Sralacues 
insert oretarsr 
return_Tabel=i_; 
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Tptr=nullo; 

rptr=nullo; 

flag=l1; 

string_leneth=nseudo_lerrth; 

string=substr(Cinnput_or_return_strinz,1,min(max_lereth, 
nseucdo_lenrth)); 

so to ins _comp_lahel (found); 


ins_comp_1t_9: 
succ=nullo; 
refno=l1717966978h; 
tent=1717986e1Ch; 
first_entry=iptr; 
successor_chain_heat=iotr; 
so to ins_incr; 


ins_comp_eaq_0: 
diff=nax_depth_of_troe-ili; 
differ=l; 
do fk=1 to diff; 
differ=2*differ; 
end; 
if turn=richt then la; 
ptr-orntr=iptr; 
Iptr->succ=ptr->suce; 
ptr- %sucesinotr; 
iptr->refno=ptr->refno+differ; 
tenttiptr->orefno; 
go to ins_incr; 
end; 
else do; 
iptr=->succ=ptr; 
ptr-> lptr=iptr; 
iptr-~>refno=ptr-orefno-‘iffer; 
tent=inotr->orefno; 
if last lriehtsnullo then sucenssor_chain_heat=intr; 
else last_right->sucesiotr: 
so to ins_incr; 
end: 


ins_st_9: 

tent=ntr-refno; 

if ntr->flars) then do; 
ptr->flaresl; 
nun_free_cells=nun_free_enlis-1; 
end; 

else go to insert_end; 

ins_iner: 

num_entries=nun_entriest+l; 


insert_end: end; 
return; 


pale So Rae 
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delete_by_refnro: 

if dbr_leb_sw=9 then cdo; 
dbr_label (-1) =dbr_1t_9; 
dbr_label(9) =dbr_eq_9; 
dchr_label (1) =dbr_¢t_9; 
dbr_lab_sw=1; 
end; 

do if = 1 to unper_bound; 
return_lahel=deleto_by_refno_return; 
mo to refno_prolotus; 
delete_hby_refno_retirn: 
fo to dhr_lahel (found); 


dbr_it_O: c>r_ea_d: 
dsm_ares.return_ptr(itdeader(mt_auart); 
mtcentecdata_tyoe; 

mtpentsser ptr; 

sao to delete_by_refno_ene; 


chrosgt_3: 

if ptr->flaz=0 then ro to chrlec_); 
else; 

ptr->flasz=9; 
num_entrics=num_entries-1; 
num_free_cells=num_frese_collstl; 
return_labele=re; 

so to strine_alloc; 
re: 

pseudo_lenrth=ptr= ostrinz_leneth; 
input_or_returr_strincvssubstr(ptr->strine,1,.%s0e140_1 
eneth); 


delete_hy_refno_end: ant; 

if 2*nun_free_cells > num_entries tron = to tree_rehu 
ild; 

return; 


[RRR KK REE REE RK ERR KEKE RK RRR EK EE KEK / 


pa 


aelete_by_datun: 
if- dbd_labosw=). then dios 
dbd_lab_swsl; 
dhd_label (el) =dbd_lt_5;3 
dbd label (G) =dbd_ee_Ct; 
dbe_ label (1) =dhbd_et_o; 
end; 


do iif = 1 to upnper_bound; 
return_label=delete_by_datun_return; 
so to datum_proloctun; 
delete_by_datum_return: 
so to dbhd_label (foun!); 


dbd_lt_O: dhd ead: 
dsm_arcs.roturn_otr(ii) sad'r(mt_quart); 
mtcentedata_tync; 

mtpentesesz ptr; 

ro ta delete_by_datun_end; 


Abd_7t_9: 
if ptr->flagr=9 then =o to cthd_en_d; 
else; 
ptr->flar=0; 
nunmLentries=nun_entries-1; 
nun_free_cells=nun_free_cells+l; 
return_label=dd; 

so to quart_alloc; 

dd: 

tent=ptr->refno; 


aelete_by_datum_end: end; 
if 2*num_free_cells > num entries then to to tree_rebu 
ila; 


return; 


LR RRR KR KIRKE ERERKE ERK KR EKER EKKKR KK KK KK EK / 
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refno_prolotue: 

1 ery EO th ap -d r(.):; 
FO AXP then guortlotredc_or_q_otr (li); 
e quert_otr=c_or_a_ntr(iid; 


als 
en_intemax_leneth; 


1 
4 
search_by_refno: 

turn, founct=%; 
if firstlentry=enullo than do; 
founds-1; 
eo to return_label; 
ends 
else ptr=firstlentry; 
if exp2!F" then oresented_loon_re onozquort_prooer, 
qgtentCti,ci); 
else presenterd_loonp_re nozquart.tert; 
ast_left, last_lriehtenulla; 
iift=] to sax_dent’_of_tree; 
stored_loon_refnesptr- item, reins; 

if presented loon urefna < stored. loaplretna then 

AG: 
if ptr-> ptr T=nullo then do 
last _left=ptr; 
slich=ptr->1rtr; 
otretlichk; 
eo to. snare’ hy retina cern: 
end; 
else do; 
turns=left; 
=O to return_label1; 
ends; 
end; 
if presentet_lonn_refna > stored_lnop_refno ther 


Ne 


do; 
if otr->Orotr =enullo then to; 


lestlriczhtsnotr; 
elich=ntr->rptr; 
ptreslich; 
so to search by_refno_en?; 
end; 
else do; 
turn=richt; 
so to return_lacel; 
end; 
end; 
if preserted_loop_refno = storect_loon_refno then 
do} 
found=1; 
mo to return_lahetl; 
end; 
search_by_refnro_end: enc; 
=O to troevrebulild; 


[RR RRR RR ER RR KR ERK ERE RK EK / 


-192- 
datum_prologue: 
str_ptr=dsm_ares.d_or_q_ptr(ii); 
nien_int=nax_len=th; 


search_hy_datun: 

Found, turn=9; 

if first lentrysnullo then do; 
found=-1;3 
mo to return_label; 
end; 

else otr=first_entry; 
presented_lnon_strinv=substr(innut_or_returnustrin 


=,l,pseudo_length) ; 
last_left, last_risht=nullo; 
do fiif=l to max_depth_of_trere; 
stored_loop_strins=substr(ptr-d>item.strine,1,%tr 
->string_leneth) ; 
if presented_loop_strine < storecd_loop_strins th 
an 
less_than: do; 
if otr-> ptr “=nullo then ca; 
last_left=otr; 
elichsptr->1ptr: 
ntreslich; 
no to search_hy_datum_ent; 
and; 
else do; 
turn=left; 
ro to return_lehel; 
and; 
enc; 
else if oresante’_loanp_strine > stored_loon_stri 


ne then 
freater_tian: cin; 
if ntr-orntr7=nullo then cn; 
last_richte=ntr; 
elich=ptr->orptr; 
ptreslich; 
so to search_by_datum_enr’d; 
end; 
else do; 
turn=risht; 
so to return_label; 
eng 
end; 
else if presentat_lonp_ustrins = stored_loon_stri 
neg then co; 
found=l; 
so to return_label; 
end; 
search_by_datun_Lend': 


: end; 
50 to tree_rehuile; 
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dsm_interer.pll 96/91/70 1811,] edt 
“ion 


dsm_integer: proc (dsm larss_ ptr); 
del data_seg area (1024) base (sex_ptr); 
del first_off offset (data_serm) hased (ser_ptr); 


dcl 1 dsm_args based (dsm_ares_ptr), 
upper_bound fixed bin (17), 
ci fixed bin (17), 

op char (1), 

di char (1), 

e char (1), 

ddptr ptr, 

d_or_q_otr (upper_hound) ptr, 
return_ptr (Cunper_bound) ptr; 


PQ PO PO BO BO DY PO PO 


dcl 1 type based (type _ptr), 
2 dsm_name char (32), 
2 data_type char (16); 


dcl 1 quart based (quart_ptr), 

ic fixed hin (35) inittal (9), 
leneth fixed hin (35) initial (1), 
order fixed bin (35) initial (1), 
cent char (32), 

pent ptr, 

tent fixed hin (35); 


BO DI Po bho hd bho 


del 1 quart_proper hased (quart_ptr), 

aid fixed bin (35), 

qleneth fixed bin (35), 

aorder fixed bin (35), 

acent (qorder) char (32), 

qapent (qorider) ptr, 

atent (gleneth,aorder) fixed hin (35); 
del 1 mt_quart static, 

id fixed hin (35) initfal (0), 
mtleneth fixed hin (35) inittal (9), 
mtorder fixed bin (35) Initial (1), 
mtcent char (32), 

mtpent ptr; 


hI BO ROD Po Po 


PO RIB PQ PO 


cdcl 1 pseudo_strine_array haser (str_—ptr), 
2 oseudo_leneth fixed bin (35), 
2 input_or_return_string char (mlen_int); 


a LOS 


der Ci ,. Tem enc int; tenn, sienpe lode iy 2 fia En C35): 


cel ell €12) cchar C1? urnalbened, 
clit char (12) defined cll(1) unaliere?; 


del (quart_otr,str ptr, suce_ptr,’sm_arcs_ntr,cor_ptr,so7_otr 
,type_ptr) npotinter; 

declare exp char(1) varyina; 

del opcode char (1) varyins; 


del dir char (168), erane char (32), rec’ fixed Ain C3505 -¢ 
ace fixed bin (17); 


del (divide, substr,null,addr) Sudltin; 
( 


del rem fixed b 


in 5) based (con ptr), 
false char (4) he 


35) 
haserl (con_ptr); 


Gol Seti CGe FY) bixe bine CS iottial. C119, 1co, 109s hate et 
600C0,1009099,1600599%04, 


15993999494 


ro 
rep) 
OQ 
ro) 
oO 
—) 
ae) 
3 
WY 
Oo 
. 


, 


1¢690000000,109539609995) static; 


[RRR RK RK KR RK ERK RR RR RRR RRR RR RK RK RR KR IRE RK KK RRR RK RRR KK KKK 


RRR KR ER RK / 


oncode=dsm_arers.op; 
seg ptreddptr; 
type_ptr=first_off; 


if opcode="R" then «o to set_refno; 
else If opcodest")" then so to ctet_datun; 
else if opcode="S" then eon to sueeessoar; 
else if opcode="N" then aco to neow_data_tyor; 
else ii=0; 
loon_2: 
ii=i+]; 
dsm_lares.return_ptr(ii)d=adir(mt_quart); 
ser_ptredaptr; 
type_ptrefirst_off; 
mtpent=ser_ptr; 
mtcentsdata_type; 
it bisupper bound then go to: lonn 27 
return; 


[RRR RR RR RO ROR OO RO RO OR RO KR KR KR KK RR KR RK RR RK KK 


ok kok ke ke / 
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successor: 
ii=0; 
loop_3: 
Ti=ite\ls 
allocate quart set (sucec_ptr); 
succ_ptr->cent=data_tynn; 
succ_ptr->pent=ser_ptr; 
return_ptr(ii)=ssuce_ptr; 
if exp="E" then quart_ptred_or_q_ptr(1); 
else quart ptr=d_or_q_. ptr(ii); 
succ_ptr->cent=quart_ptr->cent; 
succ_ptr->pent=quart_ptr->pent; 
if exp="F" then suce_ptr->tent=l+quart_ptr-> tent(i 
i,ci); 
else suce_ptr->tentel+tquart_ptr-> tent; 
if ii<upper_hound then so to loop_3 
return; 


[ERK RK KR RIK RK RE IRE RR IKK ERIK KERR ER IRE RK KI KHER KEK KEKE KK EE 


kk KKK KEK / 


get_datum: 
on fixedoverflow hecin; 
dsm_ares.return_ptr( ti) =addr(mt_quart) ; 
mtpentsse7_ptr; 
mtcentedata_type; 
end; 


izii¢+l; 

if ex pattr then quart _ptra=d_or_q_ptr(1); 
else quart _ptr=d_or_q_ptr(ii); 

mlen_int=12; 

allocate false set (con_ptr); 

allocate pseudo_strine_array sot (striptr); 
return_ptr(it)=strootr; 

if exp="F" then temnsaqtent(it,ci); 
else temp=quart_ptr->tent; 

if temp < 9 then co; 


Sien=-];3 
tempe-tenp; 
end; 
else sien=); 
i=12; 
comp: 


rem=temp; 

temp=divice(tenp, 11,35,0); 

rem=rem-10* temp; 

rem=remth &; /* ASCII conversion */ 
cll(Ci)=substr(false,&,1); 


th); 


[ROR OTITIS IR TI EIU ROI III IIT Oo a I ei tok ok 


ao 


-1 
temp” =3 then so to comp; 
sisn=-] then do; 
e11Ci)="-"; 
i=t-l; 
end; 
pseudo_lenszth=12-i; 


input_or_return_strinn=substr(cll2,i+],oseuto_lere 


if ii<upper_bound then to to loop_7; 


revert fixedoverfloaw; 
return; 


kK KKK RK EK / 


setrefno: 


ti 
loop_d: 
i 


i=itt+l; 
str_ptr=d_or_q_ptr (ii); 
allocate quart seat (quart ptr); 
cent=data_tyne; 

penteser_ptr; 

allocate rem set (con ptr); 
return_ptr(ii)=quart_ptr; 


cllissubstr(tnnout_or_return_strinz,1,os2uto_lensth 


et a ee eae 3 


Sloc=2; 


sien=1; 
end; 

else do; 
sloc=l; 
sirn=l; 
end; 

tenp=0; 

rem=9 ; 

i=sloc-1l; 

loop: 
i=i+l; 


substr(false,4,1)=cll(i); 
if (rem<48lerd57) then do; 


dsm_ares.return_ptr(ii)=aidr(mt_quart); 


mtpenteddotr; 

free quart_ptr->quart; 
fo to ent_of_sr; 

end; 
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temp=temp+t(rem-45) *pot(pseudo_leneth-i); 
end_of_gr: 

if i<nseudo_length then to to lon; 

tent=temp*esian; 

if ii < upper_bount then «a to loon); 

return; 


[RR KEIR EIR ERE IRE KIER EKER RK RK RK EK KR KE RK 
ok kote ek ee / 


; 
s_$fs_met_path_name(ser_ptr,dir,srech,ename 


call area_(1024,se7_ptr); 

allocate type set (type_ptr) in (data_sesz); 
data_type=enamne; 

dsm_name="dsm_interer"; 

if ii<unner_bound then to to 11]looon; 
return; 


[RRR RRR EERE EEE EK RK EEK KEKE KEEEKEEKERE KEK REE 
ke ee tte ae / 


end dsm_intescer; 


+1994 


dsm_chain.pll NE/O1/70 1830,8 eat 
“on 


dsm_chain: proc (dsm_ares_ptr); 


[RR IK RI KKK ERT TRIKE EERIE IK KERR KHKE KEE HE EE EKEEKEKEK KEKE KE RK 


kkKKKK KEKE / 
del data_ser area (1024) based (ser_ptr); 


dcl 1 dsm_args based (dsm_ares_ptr), 
upper_bound fixed bin (17), 
ci fixed bin (17), 

on char (1), 

di char (1), 

e char (1), 

cdptr ptr, 

d_orlq_ptr (upper_bound) otr, 
return_ptr (upner_bound) ptr; 


AKO PD £2 8 BO BO RO RO 


del 1 quart based (quart_otr), 

ic fixed bin (35) Inittal (0), 
length fixed sin (35) fnitial (1), 
order fixed hin (35) inftial (1), 
cent char (32) inttial (data_tyne), 
pent ptr initial (see_ptr), 

tent fixed hin (35); 


ho 89 PO PO 


NO po 


dcl 1 quart proper hased (quart ptr), 

qid fixed bin (38), 

alength fixed hin (35), 

agorder fixed Sin (35), 

qacent (qorder) char (32), 

apent (qorder) ptr, 

atent (qlensth,qorder) fixed hin (35); 


NN PMN ND] 


del 1 pseudo _strine_array based (str_ptr), 
2 pseudo_length fixed bin (35), 
2 input_or_return_string char (mlen_Int); 


dcl 1 type based (tyne_ptr), 

dsm_name char (16) initial ("dsm_chain"), 
data_type char (32), 

num_entries fixed hin (35), 
successor_chain_head offset (data_sez), 
max_length fixed hin (35), 

first_refno fixed bin (35); 


NM PID A Mh 
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becin_dsm_chain: 


EXP=ETaSnl_arss.6;3 
dorizdsn_ares.cl; 
opcode=dsm_arss.op; 
scs_ptr=ddptr; 
type_ptr=first_off; 


if opcode="D" then /* innut fs refnos */ 

if dori="" then so to set_datum; 

else if dori="N" then ro to delete_by_refno; 
else co to op_lerror; 

else if opcode="R" then /* data strings are input */ 
if dori=" " then go to cet_refno; 
else if dori ="D" then co to delete_by_datum; 
else if dori"! than <0 to insert; 

else go to op_error; 


else if opcode="S5" than 
if dori ="""" then ro to successor; 


else go to op_error; 


else ff opcode="t' than 
if (dorf="" & expe" ") then so to new data_tyne; 


if = 1 to upper_hound; 
return _ptr(iidsacddr(mt_quart); 
mtcentedata_tynn; 
mtpent=ser_ptr; 
end; 
return; 


op_error: do 


[RRR KR RRR KR RK KK KR KKK ERK KEKE EE KR EK RIK EEK KEKE EK KERR EK KE EK 


KKEKKEKEK / 


new_data_type: 
do fi = 1 to uprer_bound; 


call area_(102h,sec_ptr); 
call hes_$fs_set_path_name(ser_ptr,cirrane,ctrech 
,ename,code); 
allocate type set (typa_ptr) 


num_entries=0; 
call foa_("what is max lenreth for character stri 


ngs for “a>7a ?7°/",substr(dirname,1,¢rech),enane); 
call read_list_(srech); 


in (data_ser); 


~203- 
end; 
return; 


[RRR KK KEKE KKK KIRKE KK KERR KEKE K EK RK KK KK KERR KE EKER KEK 


kkk kkk kk ke / 


successor: 
do ii = 1 to upper bound; 


return_label=successor_return; 

zo to refno_ prologue; 
successor vreturn: 

return_label=s_3 
go to quart alloc; 


S_: 
if found=-1 then lenet=0; 
else if ptrenull then tent=suc 


cessor_chain_head->refno; 

else if otr->succ=nu 
Tlo then lensth=0; 
else tent=ptr~>succ~refno; 
end; 
return; 


[& RH RK RK KKK KK KEEREEKRKEKRERKEEKEKRE EK KARR KE RR KEK KEK 


kkk kek ke / 


delete_by_refno: 
do ii = 1 to upper_bound; 
return_lahel=delete_by_refno_return; 
zo to refno_prolocue; 
delete_by_refno_return: 
if found ™=1 then do; 
return_ptr(Cii)=addir(mt_quart); 


mtcentedata_type; 
mtpent=ser_ptr; 
end; 


else do; 
return_lahbelerd; 
mo to strine_alloc; 


rd: 
pseude_leneth=ptr-ostrins_lene 


th; 
input_or_return_strine=substr( 


ptr->string,1,otr->string_leneth); 
if pred=null then successor_ch 


ain_head=ptr->succ; 
else pred->succ=ptr->succ; 


free ptr-Dditen; 
num_entrfies=num_entries-1; 
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intr->strinz=substr( 


input_or_return_string,1,pseude_leneth); 


iptr->strine_lernth= 


pseudo_length; 


end; 
en‘; 
iend: end; 
return; 


[i RK RK TKR KKK RK RK KK RK EK IKK RK RK RIKER KER KK KKK KK EK 


KKEKK EK KEK / 


quart_alloc: 


allocate quart set (quart _pt+); 
return_ptr(ii)=quart ptr; 
pent=ser_ptr; 

centedata_type; 

so to return_label; 


string_alloc: 


nilen_int=max_lencth; 

allocate pseudo_strinzt_array set (str optr); 
return_ptr(ii)=stroptr; 

50 to returp_lahel; 


[RR KR RK KR RR RRR KIRK KE RRR KR KER RK KR REAR RE RE KEKE KR EK 
eek tk ee / 


refno_prologue;: 


if expe"F" then quart _ptr=d_or_a_ntr(1); 
else quart ptr=d_or_q_ptr(ii); 


search_by_refno: 
found=0; 
if successor_chain_heat=enullo then do; 
found=-1; 
ro to return_lahbel; 
endl; 
ptr=successor_chain_heact; 
pred=null; 
if excel" then presented_refnozqtent(ii,ci); 
else preseanted_refno=tent; 
refno_lecon: 
if presented_refnooptr->refno tren zo to refno_fut 


if preserted_refno < ptr->refno then do; 
ptr=pred; 
so to return_label; 
end; 


nt 


rent 
Ne 


found 
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50 tO return_farel; 
refno_futz: 

predeptr; 

slich=ptr->succ; 

if glich=nullo then ‘lo; 
go to reaturn_lasel; 
end; 

ptr=sglich; 

go to refno_loop; 


[RRR RRR ERR KEE KER EK EK RE KR KEKE RE RR KEK KH IRR REE KK RE KK ERE KEE EE 
kk KK KEKE KK / 


datun_prolosue: 
str_ptr=d_or_a_ptr(ii); 


search_hy_datum: 
fount=1; 
if successor_chain_heat=nullo then do; 
founds-1; 
fo to raturn label; 
end; 
ptr=successor_chain_head; 
predenull; 
presentec_string=substr(innut_or_return_strins,1,p 
scudo_length); 
datun_loon: 
if presented _strinn ssubstr(ptr->strins,1,otr->str 
length) then ~o to datun_futz; 
found=1; 
go to return_label; 
datum_futz: 
pred=ptr; 
slich=ptr->succ; 
if slich=nullo then do; 
so to return_label; 
end; 
ptr=slich; 
so to datunm_laop; 


ins 


[KR RK IR KK KE KK RIKI RE AKER KEE RK ERR KEKE KKK 
RKKKKKEKK KE / 


end dsm_chain; 
EOF 


Mon 


dsm_table: 
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dsm_tahte.nll 


proc (dsm_arss_ptr); 


06/01/70 1758.3 


ett 


[ERR RK RK RE RK KER ERK RR ERR KR RE KEK KR KR RRR KK RRR RE KER RK RK EKER KK 


RRR KKK KK / 


dcl data_ser area (area_size) hased (ser_ptr); 


cel 1 dsm_arrs based (dsn_arvs_ptr), 


del l 


dcl 


acl 1 


2 


No 


BS MO MD BOD PO 


upnper_bound fixed Sin (17), 
ci fixed bin (17), 

op char (1), 

di char (1), 

e char (1), 

ddptr ptr, 

dlor_q_ ptr (upper_bound) ptr, 
return_ptr Cupper_bound) ptr; 


quart based (quart_ptr), 


BRO RO RO PO RY BO 


ic fixed bin (35) initial (9), 
length fixed hin (35) [Initial (1), 
order fixed hin (35) Initial (1), 
cent char (32) initial (datatype), 
pent ptr initial (sere_ptr), 

tent fixed hin (35); 


1 quart_proner based (quart ptr), 


pseudo__ 


type 


NO BR RO A DO PO 


4 


“ 


2 


aid fixed bin (35), 

aleneth fixed hin (35), 

qorder fixed bin (35), 

acent (qorder) char (32), 

apent (qorder) ptr, 

atent (alensth,aorder) fixed hin (35); 
string_array based (str_otr), 
pseudo_leneath fixed bin (35), 
input_or_return_strines char (max_leneth); 


based (type_ptr), 


2 
2 
2 
Z 
2 


dsm_name char (16), 
data_type char (32), 
tab_off offset (data_sen), 


num_lentries fixed hin (35) initial Cin len), 


max_length fixed bin (35) initial Cin max); 


table (in_len) based (tah_off), 


2 string_leneth fixed hin (35), 
2 string char (max_leneth); 
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del 1 mt_quart static, 

mtied fixed bin (35) fj i 
mtleneth fixed hin (35) fj 
mtorder fixed bin (35) fn 
mtcent char (32), 

mtpent ptr; 


est Os 
tial (1), 


DORI DM PON 


dcl presented_string char (16%) varyine static; 
declare exp char(1) varying; 
dcl (dirname char (168), ename char (32), erech Fixed hin (3 


5)) static; 

dcl (seg_ptr,type_ptr,str_ptr,quart_ptr) ptr static; 
dcl code fixed bin (17); 

acl (addr,divide, substr,max) builtin; 

dcl dsm_args_ptr ptr; 

dcl first_off offset (data_sez) based (see_ptr); 


dcl (,ii,tab_len, in_len, in_max,ji,area_size,char_len) fixed 
bin (35) static; 


dcl return_label label (r_,s_,d_); 


[RRR RK RK KERIKERI KHER KEKE EEK RK REE KK 
RRRKKKERKKE / 


besin_dsm_table: 
seg_ptr=ddptr; 
type_ptr=first_off; 
if substr(onp,1,1)="D" then o to set _datun; /* tnput 1 
s refnos */ 
else if substr(on,1,1)5"2" then +o to tet _refno; /* 
data strinss are input */ 
else if substr(on,1,1)="S" than en to suceenssor; 
else if substr(op,1,1)=""" then ro to now_data_tynpe; 
else do if = 1 to upper_hbound; 
return_ptr(ii)=atdr(mt_quart) ; 
mtcantel!; 
mtpent=ddptr; 
end; 
return; 


[ORR RIK RR KKK KIKI KIKI EK KEKE REIKI K KKK KARR EK 
KKK KK KK / 
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new_data_tyne: 
do ii = 1 to unpper_bound; 
call hes_$fs_gset_path_nane(sec_ptr,cirname, rrech 


,enane, code); ; ; 
call ioa_("what is the number of table sntries in 


date type “a>7a 2?7/", substr(dirnane, 1l,arect),enane); 
call read_list_Cin_len) ; 
call joa_("what Is max leneth for character strine 
s in “ada ? “/",substr(dirnane, ],creck),ename) ; 
call read_list_Cin_max) ; 
area_size=nax(102h, litin_leanke (l+divideCin_max,', 35 
Pete ee 2) 
cali areca_(area_size,secs_ptr); 
allocate type# set (tyne_ptr) in (data_ser) ; 
allocate table set (tah_off) in (data_ser); 
num_entries=9; 
data_typesename; 
dsm_names"dsn_table'; 
end; 
return; 


[RRR KR RRR EEK RRR KK KEK RHEE EK EKER ERIK EK EE KEKE EE KE KEKEEARKK KEKE 


KKKKKK KK RK KK / 


get_datum: 
do if = 1 to upper_bound; 
if exp="E" then m=d_or_q_ptr(1l)->qtent(ii,ci): 
else m=d_or_q_ptr(ii)->tent; 
if ((m<=nunlentries) *& (tahle(m).strine_lencth =-1 
)) then do; 
return_lahel=d_; 
go to string_alloc; 
d_: 
pseudo_lenrth=tahIe(m).strine_leneth; 
input_or_return_strinessubstr(table(m).strineg, 1, 
pseudo_length) ; 
if di="N" then table(m).strins_lencth=-1; 
end; 
else do; 
dsm_aras. return_ptr( iti) =adir(mt_quart) ; 
mtcent=data_tyne; 
mtpent=ser_ptr; 
end; 
end; 
return; 


[EKER ERE KEEKEKHEEKEKEKREKEKKR KEE KKK KR / 
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set_refno: 
do ii = 1 to upper_bound; 
str_ptr=d_or_q_ptr(ii); 
presente’_string=substr(inout_or_return_ 
strinsg,1,pseudo_lenrth); 
do jj = 1 to num_lentries; 
if table(jj).string_lenath =] 
then 
if presented_strins= 
substr(table(jj).string,1,table(jj).strins_leneath) then so t 


Oo £rq; 


end; 
if die"! then «o to fnsert; 
else do; 
dsm_arvs.return_ptr(fi)=addr(m 
t_quart); 
mtcert=data_tyne; 
mtpentesser_ptr; 
go to i_end; 
end; 
insert: 


num_entries=num_entriestl; 
tahle(num_entries).strine_len 
th=pseudo_length; 
tahle(num_entries).strine=ssuhbs 
tr(input_or_return_string, 1,pseudo_lenrth); 
jj=num_Lentries; 
grq: 
return_label=r_; 
m0 to quart_alloc; 
rot 
tent=jj; 
if di="BD" then table(ji).strinz_lensth=- 


i_end: end; 
return; 


[KK KK KKK KI KK RK IK KK EK KIT KKK RR EK KRHA KK KA KKK KK 
EKKKKKKKK EK / 


successor: 
do if = 1 to upper_hound; 
if exp="F" then m=d_or_q_ptr(l)->aqtent (i 
i,ci); 
else m=c_or_q_ptr(ii)->tent; 
return_label=s_; 
£o to quart_alloc; 
Su: 
if mnumlentries | m<0 then do; 
return_ptr(ii)=addr(mt_quart); 
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free quart ptr->quart; 
mtcent=data_type; 
mtpent=se2 ptr; 
fo to suce_end; 
end; 
sloop: 
m=m+ 1; 
if mnunentries then length=9; 
if table(m).strine_leneth=-1 then so to 
sloop; 
tent=m; 
succ_end: end; 
return; 


[RR RRR RR RRR RIK KR HK IKKE K ER ER ERE KKK KEE KEKE KEKE KE KK KEKE EEE 
kaK KKK KKK / 


quart_alloc: 
allocate quart set (quart_ptr); 
penteses_ntr; 
cent=data_tyne; 
return_ptr(ii)=quart ptr; 
go to return_lahel; 


string_alloc: 
allocate pseudo_strings_array set (str iptr); 
return_ptr(if)=str ptr; 
so to return_label; 


[RR KR KK RK KKK RR KR KKK RK KEKE REE RIE EERE KKK HERE KEK KK EK K 
kkk kkk eK / 


end dsm_table; 
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rsmiviq.pll 06/03/7. 1014.5 edt 
wed 


rsm_wa: procedure(arg ptr); 
declare l args hased (arg ptr), 
2 upper_hound fixed hin(35), 
2 op character(1), 
2 qlptr (limit refer (upper_hound)) pointer, 
2 rl_ptr (limit refer (upper_bound)) pointer, 
/*Not used here*/ 
2 q2_ptr (limit refer (upper_bound)) pointer, 
2 r2_ptr (limit refer (upper_bound)) pointer, 
/*Not used herex/ 
2? equiviptr (limit refer (upper_bound)) pointe 
r, /*Not used here*/ 
2 return_arg (limit refer (upper_bound)) point 
er; 
declare 1 quart based (Iptr), 
2 1D fixed bin(35) initial(0), 
2 length fixed bin(35), 
2 order fixed bin(35), 
2 cent(alloc_order refer (order)) char(32) 
2 pent(alloc_order refer (order)) pointer, 
2 tent(alloc_length refer (length),alloc_order 
refer (order)) fixed bin (35); 
declare 1 ent_vector hased (rptr), 
2 width fixed bin(35), 
2 names(alloc_order refer (width)) char(32); 
declare J] int_sort_quart, 
2 sid fixed hin(35) initial(Q), 
2 slength fixed bin(35) initial(0), 
2 sorder fixed bin (35) initial(20), 
2 scent(sorder) char(32); 
declare 1 feht based (eq_ptr), 
2 num fixed hin(35), 
2 newcent (1 refer (num)) char(32); 
declare return _place label (major_loop,in_UID_op,i 
ne. Pops, RC. op. 1, Tne 6p..273 
declare op_label label (U!D_operate,S_operate, P_op 
erate, X_operate, Z_operate,M_operate, 
F_ operate, _operate,O_oper 
ate, C_operate); 
declare q_alloc_r label (q_alloc_1,q_alloc_2,q_all 
oc_3,q_alloc_4,q_alloc_5,q_alloc_€&,aq_alloc_7,q_alloc_8); 


declare (gen_purpose_ptr,new_ptr,free_ptr,eq_ptr,t 
ptr,cptr) pointer; 

declare (Iptr,rptr,temp_ptr,temp2_ptr,temp_Iptr,te 
owp_rptr) pointer; 

declare (null,max) builtin; 
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declare corres(slengsth) fixed bin(35) based (gen_p 
urpose_ ptr); 

declare token(slength) fixed hin(35) hased (ren_pu 
rpose_ptr); 

declare int_cent(20) char(32); 

declare alloc_cent(20) char(3?); 

declare cent_flag(20) fixed initial((29) 9); 


declare temp fixed bin(35); 

declare (n_sw,no_sort_sw) fixed bin (1); 

declare (step_sw) fixed bin(1) initial(0b); 

declare (Iplace,rplace,oplace,tplace,alloc_order,a 
lloc_length,entry_count) fixed bin(17); 

declare (slength,rrow,rcol,lrow,lcol,nc,nr,cl,|lt,r 
t,free_len,free_ord) fixed bin(17); 

declare (ii,jj,kk,l1,mm,i,j,limit,ocount,place,chu 
nk) fixed hin(17); 

declare (llensth,rlength, lorder,rorder, 1_new_order 
) fixed bin(17); 


if args.op="U"largs.op="I"largs.op="D" then op_lah 
el=UID_operate; 
if args.op="P" then op_label=P_operate; 
if arss.op="S" then op_label=S_operate; 
if args.op="X" then op_lahbel=X_operate; 
if args.op="0" then op_label=0_operate; 
if args.op="C" then op_label=C_operate; 
if args.op="E" then op_lahel=E_operate; 
if arss.op="M" then op_label=M_operate; 
if args.op="Z" then op_label=Z_operate; 
if args.op="0" then op_label=N_operate; 


do kk=1 to args.upper_bound; 

if args.op="U"largs.op="["largs.op="D" then go to 
no_set_ptrs; 

Iptr=arges(kk).ql_ptr; 

rptr=args(kk).q2_ptr; 
no_set_ptrs: 

return_place=major_loop; 

fo to op_lahel; 


quart alloc: allocate quart set (temp_ptr); 
go to q_alloc_r; 


E_operate: alloc_order=order; 
allocate ent_vector set(arges(kk).return_arg); 
do {=1 to alloc_order; 
ares(kk). return_arg->names(i)=cent(i); 
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end; 
sQ to return_place; 


Z_operate: args(kk).return_arestptr; 
do i=l te order; 
sentCidenull; 
end; 


fo to return place; 


i_operate: args(kk).return_ares=lIptr; 
if width7=arder then do; 
Call CScerrorepr ig 34.1", Lotryratris 
ares.return_arg(kk)=nuli; 
ro to return_place; 


end; 
do j21 to order; 

if names (i)7="&'" then cent(i)=names(i); 
end; 


sO to return_place; 


O_ operate: if width7=order then do; 
call GS_error$pr(103,"0",Iptr,rptr); 
null_answer: args.return_arae(kk)=null; 
ro to return_place; 
end; 
sleneth=order; 
alloc _order=slensth; 
allocate ent_vector set(cptr); 
Allocate token set(tptr); 
bee 
do mm=1 to order; 
if names(rm)="2" then cptr- >onfames (im) =cent (mn) 


else cptr- names (mm)=names (inn) ; 
if names(mn)7s" " then da; 
tptr->token( jj )=nm; 
By one eee 
end; 
end; 
i peer then alloc ordere7 j= 13 
else eo to null_answer; 
alloc_lengeth=lensth; 
a_alloc_r=a_alloc_7; 
£9 to auart_alloc; 
a_alloc_7:tplace=l; 
do mm=1 to alloc_order; 
tenp_ptr->cent(mm)=cptr- oOnanes(tptr-> token (mn) 
)3 
temp_ptr- pent (mm)=null; 
end; 
do jj=l to leneth; 
rosweOh; 
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if tent(Ilplace,oplace)>rptr->tenti(rpiace,opiac 
e) then do; 
if arss.ops"U" then do; 
do ocount=1 to alloc_order; 
temp_ptr->tent(tplace,ocount )=rptr 
->tent(rplace,ocount); 
end; 
tplace=tplacetl; 
end; 
if rptr->length>rplace then do; 
rplace=rplace+l; 
go to neworder; 
end; 
else finish_left: do place=Iplace to lengt 
h while(args.op="U"Jargs.op="D""); 
do ocount=1 to alloc_order; 
temp_ptr->tent(tplace,ocount )=tent 
(Iplace,ocount); 
end; 
tplace=tplacet+l; 
end; 
20 to stop_action; 
end; 
else do; 
if arzs.op="U"|args.op="D" then do; 
do ocount=l1 to alloc_order; 
temp_ptr->tent(tplace,ocount )=tent 
(Iplace,ocount); 
end; 
tolace=tplace+l; 
end; 
if length>Iplace then do; 
Iplace=l]place+l; 
zo to neworder; 
end; 
else finish_right: do place=srplace to rptr 
->length while(args.op="U"'); 
do ocount=1 to alloc_order; 
temp_ptr->tent(tplace,ocount )=rptr 
->tent(rplace,ocount); 
end; 
tplace=tplace+l; 
end; 
70 to stop_action; 
end; 
end; 
else do; 
if order>oplace then do; 
oplace=oplacetl; 
=o to check; 
end; 
if ares.on="D" then go to nocopy_right; 
do ocount=1 to alloc_order; 
temp_ptr->tent(tplace,ocount)=tent(Iplace, 
ocount); 
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end; 
tplace=tplace+l; 
nocopy_right: if length ™>Iplace then do; 
if rptr->length>rplace then do; 
rplace=rplacetl; 
zo to finish_right; 
end; 
else go to stop_action; 
end; 
else do; 
Iplace=Iplacetl; 
if rptr->length >rplace then go to finish_ 
left; 
rplace=rplace+l; 
7Q to neworder; 


stop_action: oplace=alloc_length; 
alloc_length=tplace-1; 
if alloc_length=oplace then go to no_new_copy; 
temp2_otr=temp_ptr; 
q_alloc_r=q_alloc_2; 
zo to quart_alloc; 
q_alloc_2: do jj=#l to alloc_order; 
tenp_ptr->cent(jj)=cent (jj); 
tenp_ptr->pent(jj)=pent( jj); 
do mm=] to alloc_length; 
temp_ptr->tent (mm, jj )=temp2_ptr->tent (im, j 
+); 
a end; 
end; 
alloc_lensth=oplace; 
free temp2_ptr- quart; 
no_new_copy:arges(kk).return_arg=temp_ptr; 
go to return_place; 


P_operate: if rptr=null then go to set_first_element; 
if rptr->length=0 then so to get_first_element; 
alloc_order=order; 
slensth=alloc_order; 
if rptr->order“=alloc_order then do; 
args.return_arg(kk)=null; 
call GS_errorspr(10l,op,1]ptr,rnptr); 
eq to return_place; 
end; 
allocate corres set (cptr); 
do iji=1l to alloc_order; 
do jj=#l to alloc_order; 
if rptr->cent(jj)=cent(ii) then do; 
eptr->corres(ii)=rptr->tent(1, jj); 
Zo to next_step_on; 
end; 
end; 
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C_operate: 

eq_ptr=equiv_ptr(kk); 
llength=Iptr->lensth; 
rlength=rptr->length; 

rorder=rptr->order; 

lorder=lptr->order; 

if (lorder+rorder)“=feht.num then 

call GS_error$p(105,"C",eq_ptr,null); 


/* 1. put new bindings in int_cent */ 


do | = 1 to lorder; 
if neweent(i)="a" then int_cent(i)=Iptr->cent ( 
i); 


else int_cent(i)=newcent (i); 
end; 


do j = 1 to rorder; 


if newcent(lorder+j )="&" then int_cent (lorder+ 
j)=rptr->cent(j); 


else int_cent(lorder+j )=newcent(lorder+j); 


end; 
/* 2. sort left quart on cents in domain of lambda (see thes 
is) */ 
Isort: k=l; 
sorder=lorder; 
do i=l to lorder; 
if cent_flag(i)=L]int_cent(i)=" " then go to 1 
nofill; 
do m=lorder+1 to lordertrorder; 
if int_cent(m)=int_cent(i) then do; 
cent_flag(i)=1; 
scent(k)=Iptr->cent(i); 
k=k+1; 
zo to jtest; 
end; 
end; 
zo to Inofill; 
jtest: do j=i+l to lorder; 
if int_cent(i)=int_cent(j) then do; 
cent_flag(j)=1; 
scent(k)=Iptr->cent(j); 
k=k+l1; 
end; 
end; 
inofill: end; 
contin: do i = 1 to (lorder-1); 
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if cent_flag(i) = llint_cent(i)=" " then go to 
liend; 
cent_flag(i)=1; 
scent(k)=Iptr->cent(i); 
k=k+1; 
do j = (i+1) to lorder; 
if int_cent(i)=int_cent(j) then do; 
cent_flag(j)=1; 
scent(k)=Iptr->cent(j); 
k=kel; 
end; 
liend: end; 
do i=l to lorder; 
if cent_flag(i)=0 then do; 
cent_flag(i)=1; 
scent(k)=Iptr->cent(i); 
k=k+1; 
end; 
end; 
rptr=addr(int_sort_quart); 
return_placerin_C_op_1; 
go to S_operatec; 
in_C_op_l: temp_ptr=return_arg (kk); 
temp_Iptr=temp_ptr; 
rptrsa2_otr(kk); 
do i = 1 to lorder; 
do j = 1 to lorder; 
if temp_ptr->cent(i)=Iptr->cent(j) then 
temp_ptr->cent(i)=int_cent(i); 
end; 
end; 


/* 3. check right quart for need to sort */ 


rsort: 
k=]; 
sorder=rorijler; 
rptr=q2_ptr(kk); 
do i = lorder+l to lordertror‘er; 
if cent_flag(t)=llint_cent(j)=" " then go to r 
nofill; 


do j=l to lorder; 
if int_cent(i)=int_cent(j) then do; 
cent_flag(i)=1; 
scent(k)=rptr->cent(i-lorder); 
k=ek+l; 
so to intest; 
end; 
end; 
zo to rnofill; 


mtest: qo mziti to reAter+iorser: 
if int_cent(i)=int_cent(m) then do; 
cent_flag(m)=1; 
scent(k)=rptr->cent(m-lorder); 
kek+l; 
end; 
end; 
rnofill: end; 


do i = (lordertl) to (lordertrorder); 
if cent_flag(i)=llint_cent(i)=" " then go to r 
lend; 
cent_flag(i)=1; 
scent (k)=erptr->cent(i-lorder); 
kek+1; 
do m=i+l to lordertrorder; 
if int _cent(m)=int_cent(i) then do; 
cent_flag(m)=1; 
scent(k)=rptr->cent(m-lorder); 
k=k¢+l1; 
end; 
end; 
riend: end; 
do j#l+lorder to lordert+rorder; 
if cent_flag(i)=0 then do; 
cent_flag(i)=1; 
scent(k)=rptr->cent(i-lorder); 
k=k+1; 
end; 
end; 
Iptr=rptr; 


rptr=addr(int_sort_quart); 
return_place=in_C_op_2; 
zo to S_operate; 
in_C_op_2: temp_ptr=return_arg (kk); 
rptr=q2_ptr(kk); 
Iptr=temp_lIptr; 
do 1 = £ to rorder; 
do j = (lorder+1) to (lorder+trorder); 
if temp_ptr->cent(i)=rptr->cent(j-lorder) 
then 
rptr->cent(j-lorder) = int_cent(j); 
end; 
end; 


Alloc_order=]; 
do i = 1 to (lorder-1); 
; if Iptr-dcent(i)=Iptr->cent(i+1) then go t 
o aliend; 
else if Iptr=->cent(i) "=" " then do; 
alloc_cent(alloc_order )=Iptr->cent(i); 
alloc_order#alloc_order+]; 


en 


o ariend; 


o ariend; 


en 


q_alloc_8: 


begin_compose: 
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end; 
aliend: end; 
if Iptr->cent(lorter-1)7=Iptr->cent(lorder) th 


if lptr->cent(lorder)7=""" then do; 
alloc_cent(alloc_order)=Iptr->cent (lorder) 


alloc _orderzalloc_order+1; 
end; 
l1_new_order=alloc_order-1; 


to (rorder-1); 
= 1 to 1l_new_order; 
alloc _cent(j)=rptr->cent(i) then go t 


do | = 1 
do j 
if 


end; 
if rptr->cent(i)=erptr->cent(it+l) then go t 


else if rptr->cent(i)7=" " then do; 
alloc_cent(alloc_order)=rptr->cent(i); 
alloc_order=alloc_order+tl; 
end; 
ariend: end; 
if rptr->cent(rorder)“=rptr->cent(rorder-1) th 


if rptr->cent(rorder)7=" " then do; 
alloc_cent(alloc_order)=rptr->cent(rorder) 


alloc_order=alloc_ordertl; 
end; 
alloc_order=alloc_order-1; 
alloc_length=rlength+*llength; 
temp_rptr=temp_ptr; 
q_alloc_r=q_alloc_8; 
zo to quart_alloc; 
new_ptr=temp_ptr; 


do i = 1 to alloc_order; 
new_ptr->cent(i)=alloc_cent(i); 
end; 

fo | = 1 to lorder; 


if rptr->cent(l)=Iptr->dcent(i) then cl =i; 


end; 


lrow, rrow,nr=1; 


row_incr: 
if lrow>llength|rrow>rlength then do; 
nr=nrel; 
7Oo to return_sequence; 
end; 
if Iptr->tent(lrow,cl)<rptr->tent(rrow,1) then do; 
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lrow=lrow+]; 
70 to row_incr; 
end; 
if lptr->tent(lrow,cl)>rptr->tent(rrow,1) then do; 


rrow=rrowt+l; 
so to row_incr; 
end; 


one_compose: 
lcol,rcol,nc=l; 
Ir_comp: 
if Iptr->cent(lcol)“=rptr->%cent(rcol){lptr->cent (1 
col)="" " then do; 
lcol_iner_9: 
lcol=lcol+l; 
if lcol>lorder then do; 
new_ptr->tent(nr,nc)=lptr->tent(lrow,Ilcol- 


5 
ne=nct+l; 
2a to right_finish; 
end; 
else if Iptr->cent(}Icol)=" " then go to lcol_i 
ner_0; 
else if Iptr->cent(1lcol )=Iptr->cent(Ilcol-1) th 
en 


if lptr->tent(lrow,1lcol )=lptr->tent(lrow,] 
col-1) then 
go to Icol_incr_9; 
else do; 
lrow=l]row+t+l; 
ZO to row_incr; 
end; 
else do; 
new_ptr->tent(nr,nc)=lIptr->tent(lrow,lcol- 
1); 
nce=nc+l; 
so to Ir_comp; 
end; 
end; 
else if lcol>=lorder then do; 
leol=lIcol+l; 
if Iptr->tent (lrow,]col-1)"=rptr->tent(rrow,re 
ol) then go to right_finish; 
else do; 
new_ptr->tent(nr,nc)=Iptr->tent (lrow,}col- 
1); 
nce=nctl; 
fo to risht_finish; 
end; 
end; 
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else if Iptr->cent(lcol)=Iptr->cent(Icol+l) then 
if lptr->tent(lrow, lcol )7=Iptr->tent(lrow,icol 
+1) then do; 
Trow=)]rowtl; 
go to row_incr; 
end; 
else do; 
lcol=lcol+l; 
go to Ir_comp; 
end; 
else if rcol>=rorder then do; 
rcol=rcol+1; 
if lptr->tent(lrow,1lcol)"=rptr->tent(rrow,rcol 
-1) then go to left_finish; 
else do; 
new_ptr->tent(nr,nc)=rptr->tent (rrow,rcol- 
1); 
ne=nc+l1; 
zo to left_finish; 
end: 
end; 
else if lIptr->tent(lrow, lcol)7=rptr->tent(rrow,rco 
1) then do; 
if lptr->tent(lrow,cl) <¢ rptr->tent(rrow,1) th 
en rrow=rrow+l; 
else lrow=l]row+l; 
zo to row_Incr; 
end; 
else do; 
new_ptr->tent(nr,nc)=lIptr->tent(lrow,1lcol ); 
Icol=slcol+l; 
rcol=rcol+l; 
ne=nerl; 
go to Ir_comp; 
end; 


right_finish: 
if rcol>rorder then do; 
nr=nrt+l;3 
if Iptr->tent(lrow,cl) < rptr->tent(rrow,1) th 
en rrow=rrowtl; 
else lrow=lrow+l; 
so to row_incr; 
end; 
else if rptr->cent(rcol)="'" then do; 
reol=rcol+l; 
zo to right_finish; 
end; 
else if rptr->cent(rcol )=rptr->cent(rcol+1) then 
if rptr->tent(rrow, rcol )=rptr->tent(rrow,rcol+ 
1) then do; 
rceol=rcol+l; 
go to right_finish; 


By et 
end; a 


else do; 
if lptr->tent(lrow,cl) < rptr->tent(rrow,1 
) then rrow=rrow+l; 
else lrow=lrow+l; 
go to row_incr; 
end; 
else da; 
new_ptr->tent(nr,nc)=rptr->tent(rrow, rcol ); 
ne=nc+l; 
rcolercoltl; 
eo to right_finish; 
end; 


left_finish: 
if Icol>lorder then do; 
nr=nrt+l1; 
if Iptr->tent(lrow,cl) < rptr->tent(rrow,1) th 
en rrow=rrowtl; 
else lrow=lrow+l; 
zo to row_incr; 
end; 
else if Iptr->cent(lcol)=" " then do; 
Tcol=lcol+l; 
zo to left_finish; 
end; 
else if Iptr->cent(lcol)=Iptr->cent(Icol+1) then 
if lptr->tent(lrow,1lcol)=Iptr->tent(lrow, lcol+ 
1) then do; 
lcol=lcol+tl; 
zo to left_finish; 
end; 
else do; 
Jrow=l]rowtl; 
zo to row_incr; 
end; 
else do; 
new_ptr->tent(nr,nc)=lIptr->tent(lrow,1col); 
ne=nctl; 
lcol=tcol+l; 
zo to left_finish; 
- end; 


tplace=nr-1; 

free temp_Iptr->quart; 
free temp_rptr->quart; 
return_place=major_loop; 
zo to stop_action; 
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S_operate: slength=length; 
if rptr=null then zo to skip_1l; 
if order“=rptr->order then do; 
args(kk).return_arge=null; 
call GS_errorspr(10l,op,lptr,rptr); 
zo to return_-olace; 
end; 
/*Error here is unequal orders in sort*/ 
skip_l: alloc_length=length; 
allToc_order=order; 
no_sort_swe=lb; 
allocate token set (tptr); 
allocate corres set (cptr); 
if rptr=null then do; 
do ji=1l to alloc_order; 
corres(li)=#ii; 
end; 
zo to skip_2; 
end; 
do fi=l1 to alloc_order; 
do jj=1 to alloc_order; 
if rptr->cent(ii)=cent(jj) then do; 
cptr->corres(ii)=jj; 
if ii7tsjj then no_sort_sw=0b; 
go to one_corres_own; 
end; 
end; 
ares(kk). return_arg=null1; 
free cptr->corres; 
free tptr->token; 
call %S_errorspr(102,o0p,1lptr,rptr); 
so to return_place; 
/*Error here is inconsistant entries in the two cent tuples* 
/ 
one_corres_down: end; 
/*Set up the tptr->tokens*/ 
skip_2: do ii=1 to alloc_length; 
tptr->token(ii)=ii; 
end; 
/*Main sort*/ 
if no_sort_sw then go to sort_done; 
do if=l to altloc_length; 
do jj=l to (alloc _length-1); 
n_sw=0; 
do mm=1 to alloc_order; 
if tent(tptr->token(jj),cptr->corres(m 
m))>=tent(tptr->token(jj+1),cptr->corres(mm)) then do; 
temp=tptr->token(j j+1); 
tptr->token(jj+l)=tptr->token(jj); 


tptr->token(jj)=temp; 
n_sw=l; 
Zo to pop_extra_loop; 
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end; 
end; 
pop_extra_loop: end; 
if n_sw=0 then go to sort_done; 
end; 
sort_done: q_alloc_r=q_alloc_4; 
go to quart_alloc; 
q_alloc_4&: do ii=1l to alloc_order; 
temp_ptr->cent(ii)=cent(cptr->corres(ii)); 
temp_ptr->pent (if )=pent(cptr->corres(ii)); 
# do jj=1 to alloc_length; 
temp_ptr->tent(jj,il )=tent(tptr->token( jj) 
,cptr->corres(ii)); 
end; 
end; 
free tptr->token; 
free cptr->corres; 
args(kk).return_arg=temp_ptr; 
go to return_place; 


major_loop: end; 
return; 


error: end; 
cat 
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<worsm_q.pll 06/02/76 2935.7 edt 
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rsin_q: procedure(arsptr); 
declare 1 ares hased (arceptr), 
bound fixed 5in(35), 
op char(1), 
alptr (lirit refer (hount)) pointer, 
riptr (lirit refer (bouncd)) pointer, 
q2ptr (limit refer (boundc)) pointer, 
r2ptr (limit refer Chound)) pointer, 
eptr (lirit refer (bounc’)) pointer, 
retptr (lirit refer (bound)) pointer; 
declare marg$cq ontry external returns(pointer); 
declare 1 quart based (quart ptr), 
ID fixed bin€ 35) tnitial(d), 
leneth fixed *in(35), 
order fixed hin(35), 
cent(alloc_lorder refer (order)) char(32), 
pent(alloc_lorder refer (orrer)) nointer, 
2 tentlalloc_leneth refer (lencth),alloc_lor“’er 
refer (order)) fixed bin(35); 
declare oset bit€1*) hased (¢en_purnsse_ptr); 
declare new_area area (arra_size) basad (retptr(kk 


NO BO PO RO BO DD DO NO 


YN PORDAS PO 


123 

declare old_area area (area_size) based (rintr(kk) 
> 

declare old_area2 area (area size) based (r2ptr(kk 
bee 


declare 1 header based (hdroptr), 
2 rsmoname char(15), 
2 nane_r char(32), 
2 quart_location offset (old_area); 
declare (alToc_lenrth,alloc_ordoer,area_size,jj,'%, 
limit,mm) fixed bin(17); 
declare (argptr,sen_purnose_ptr,bdr_ptr,new_ares_p 
tr,quart_ptr,use) pointer; 


if op="N" then to to no_call; 
Timit=hound; 
allocate ares set (new_lares_ptr); 
new_arss_ptr-Oon=on; 
if op="R" then do; 
do kk=1l to lirit 
if qiptr(kk) 


“=null then new_ares_ptr-oretp 
tr(kk)=qliptr (kk); 

else if addrel(riptr(kk), rletr( kk) -oset)- 
rsm_q'" then do; 


newlarss_ptr->retotr(kh) =nmersealrinotr( 


~~ 


>rsm_nanie 


Rh); 
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else now larns_ptr->retotr(kh)saddrel(riptr 
(khK),rlptr(kk)->oset) >> quart location; 
end; 
so to no_call; 
end; 
do kk=1l to limit; 
Vf -qiptre (kk) “snail ehanm doa; 
new_arezs_otr->qinptr(kk)=qlptr(kk); 
and; 
if q2ptr (kk) T=null then co; 
new_arrs_ptr->q2o0tr( kk) =q2otr(kk); 
end; 
if riptr(kk)7=null ther do; 
new_ares_ptr->Oqintr(kk)=notnter(Caddrel (rip 
EER ES on clare ner ene Ue pn 
end; 
if r2otr(kk)Tsnull then eo; 
if addrel€r2ptr(kh), r25trCkl)-oset)-rse_ 
name ="rsr_q" then 
new_ares_ ptr->q2otr(kk) =mersena(r2otr(k 
Kk); 
else new _ares_ptr->q2ntr(kl) =pointer(Cadire 
VCr2ptr¢kk),r2ptr(kk) -oset)->quart_locatior, old_area”); 
end; 
new_arss ptr~riptr(kh),new_arcvs_ptr—->r2otr (kk 
),new_arss_ptr->retptr(kk) =null; 
new_ares_ptr-eptr(kk) =eptr( kk); 
end; 
call rsmwa(new_ares ptr); 
no_call: do kk=1 to limit; 
quart ptrenew_ares_ptr->retotr(kk); 
area_sizn=divice(quart_ptr->leneth*quart_ptr-> 
order+1050,1024,17,0)*1024; 
call area_(area_size,retptr(kk)); 
allocate header in (new_arca); 
rsm_name="rsm_q"; 
if op="N"" then zo to skinit; 
alloc_length=quart_ptr->lencth; 
2lloc_order=quart_ptr->order; 
allocate quart set (use) fin (new_area); 
addrelCretptr(kk), retptr (kk) -oset) ->quart_loac 
ationsoffset(use,new_area); 
do jj=l to alloclorder; 
use->cent( jj) =quart_ptr->cent( 
use->pant(jj) =quort_ptr->pent( 
do mi=l to alloec_lenrth; 
use-~>tent(mn, jj)=quart_ptr->tent (nr, jj 


. . 
j/le 
lf; 


: 
J 


end; 
end; 
if opT="R" then free quart _ptr->quart; 
end; 
free new_arss_ptr-arcs; 
skipit: end; 


Tue 
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s>tree.pll 06/02/79 1244.9 edt 


PRELIMINARY VERSION 


tree_restructure: pro 


acl 


del 


del 


del 


del 


cedure (dsrares_ptr); 


data_seg area (area_size) based (ses_ptr); 


1 


quart based (quart ptr) , 
ic fixed binary (35) initial (0), 
leneth fixed bin (35), 


NO Bah HO BO BO 


mM 


NO PO AO PO PO BO BO 


order fixed 
cent (2) c¢ 
pent (2) p 


bin (35) tinitial(2), 
har (32) , 
tr, 


tent (alloc_leneth refer (leneth),2) fixed tin (35 


upper_dound 
op char (1) 
di char (1) 
e char (1) 
d_or_q_ ptr 
ddptr ptr, 
return_ptr 


ism_arss hased (dsm_ares_ptr) , 


fixed binary (35) Initial(1), 
Initial (me), 

Pa ead: C15 

inittalr €% ™, 

ptr, 


ptr; 


type based (type_ptr) , 


RON NOMA bo 


RIND hO PIRI PO 


2 dsm_name 

data_type c 
num_free_ce 
nun_entries 
max_length 

first_entry 
successor_c¢ 


tem based (i 
lptr offset 
rptr offset 
suce offset 
flan fixed 
refno fixed 
string_stru 
3 string_le 
3 string ch 


char(1S), 
har (4), 

lls fixed hin (35), 

Fixed bin (35), 

fixed hin (35), 

offset (data_see), 
hain_head offset (data_seo); 


otr) , 
(data_sec), 
(data_sesr), 
(data_se7), 
‘inary (35), 
hin (35), 
cture, 
neath fixed hinary (35), 
aracter (max_leneth); 


area_fake based (fakn_ptr), 


Z 
2 
2 
2 
2 


first_off 

tprewq_fake 
curr_len b 
qeeudm_fake 
next_offset 


bit (16) unaliened, 
bit (18) unaliened, 

it (18) unalirned, 
bit €18) unaliered, 
hit €18) unaliened; 
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declare (new _ptr,xfer,new_hdr) pointer; 
declare (next,temp_offset) offset (data_sen); 
declare (new_item_offset,last_new_itenm_offsot) of f 


set (new_dd_area); 
declare (left_save,answer) (35) offset (data_sec); 


declare (off_hdr,alloc_lenzth,qsiza,qplace, level,c¢ 
unmi,nn,expo) fixed hin(17); 

declare (stem,nunber) (35) fixed bin(35); 

declare new _dd_area area (area_size) based (new_dd 
apErIs 

declare back (35) lahel (ton_of_trer,ceil_recur, f 
oor_recur); 

declare new_q_area area (area_size) based (new_q_p 
tr); 

declare (wdir, input place) char(16°); 

declare err_code fixed hin (17); 


allocate dsm larss set (new ptr); 
call hes_$fs_search_get_wdir(addr(wdird,jji); 
call hes_$make_ser(weir,data_type] ["_CS_new'data_ 
typel |"_GS_new", 1011b,new_de_ptr,err_code) ; 
if err_code>0 then ‘lo; 
call ftoa_("Frror has occured in allocating new 
segment for data type “4a. File error code= “60.", 
data_type,err_code); 
call fioa_("When you wish to continue, type any 
thing and hit return.''); 
call ios $read_ptr(adedrCinput_place),1,jji); 


end; 
call hes_$make_sex(wdir,cata_typel |"_converston_qu 
art", cata_type] |"_conversion_quart", 10114, 


new_q ptr,err_code); 
if err_code>0 ther co; 
call ioa_("frror has occured in allocating new 


serment for conversion quart."); . 
call joa_("fata tyne is “ba, File error code j 


s “ho.'lata_type,err_code) ; 
call fjoa_l(™hen you wist to cantinue, type any 
thing and hit return."); 
call fos_$read_ptr(ader(innut_place),1,jjj); 
end; 
type_ptreaddrel(ddotr, tdotr->first_off); 
new _ hdreaddrel (nevw_de_ptr,new_dd_ptr->first_of ©); 
alloc_leneth=nun_entries; 
asfre=2*alloc_lencth+102%425; 
Cs izesdividecgsize, 12h 97, Co #1024; 
call area_Caqsize,new_q_ptr); 
allocate quart set(quart_ptr) in (new _q_arra); 
pent(]),pent(2)=null; 
cent(1l)=data_typo; 
cent(2)=data_type| {"_GS_ now"; 
return otrezdquart otr: 
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call hes_Smake_ptr('", dsm_nane,dsm_nane,xfer,err_c 
ode); 
if err_code>O then clo; 
call foa_C"Illeral call te tree restructure -f 
3M for old version of data tyne ‘laes not exist."); 
call GS_errorser(96,"T",dsm_nane, null); 
end; 
call cu_$otr_call(xfer,new_ptr); 


new_tree: nunber(1)=alloc_lencth; 
next=suceessor_chain_hea’l; 
stem(7) =169099939999999099999999997999099990h; 
back(1) =ton_of_tree; 
aplecesl; 
levele=l: 
s0 to optim; 


optim: /*procedure (nunber,sten) returns ansvert/ 
if number(level)=9 ther «oa; 
ansver(level)=nallo; 
so to hack lavel); 
end; 


if number@evel)=1 then do; : 
allocate item in (new _dd_area) set (new_iten_o 


ffset); 
new_iten_offset->flac=]; 
last _new_item_Loffset->succ=ne!_item_offset; 
last_new_iten_offsetanew_iten_offset; 
answer(level)=next; 
new_item_offseat-> lotr, nav_iteam_offset->rotrenu 
Tlo; 


new_ttem_af€set-orefnozston(lovel); 

tentlqnlace, 1) =next->refno; 

tentCqplace, 2) =new_item_offset->refno; 

qplacefqplacetl; 

if qplace=1 then nev_hedr->successor_chain_head 
=new_item_offset; 

temp_offset=next->succ; 

next=temp_offsct; 

ro to back(level); 

end; 


level=level+l; 

number (level) sdivice (number (level-1)4+1, 2,17,1%) 

Floatersdivide(number(level-1)41,°,17,%; 

if floater>float(number(level),17) then number(lev 
el)=number(level) +1; 

expo=nax_depth-level; 


we 
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cumsl;3 
do mn=l to expo; 
cum=cu*2; 
end; 
stem level) =ssten(level-1)-cur; 
back( level) =ceil_recur; 
£0 to optin; 
ceil_recur: left save( level) =ansywer(level); 
answer(level-1)=next; 
temp_of fset=next->sunc; 
next=temo_offset; 
number (level) =divide (number(level-1)4+1,2,17,9); 
expo=nax_leneth-level; 
cunesl; 
da nn=1 to expo; 
CUN=CUN* 2 3 
end; 
sten(Clevel)=estam(level-l)+cun; 
back( level) =floor_recur; 
so to optir; 
floor_recur: allocate item in (nev_dd_area) set (new_iten_of 
fset); 
new_item_offset->flace=l; 
new_item_offset->Inotr=left_save(leval); 
new_item_offset-Orotr=arsvwer(lovel); 
new_item_offset->refnozstom(level-1); 
last_new_item_offset->succ=new_itom_offset; 
last_new_item_offsetsnew_item_offset; 
tent(aplace, ]) =ansver(level-1)->refno; 
tent(qplace,2)=new_iten_offsst—->refno; 
qplacetuplacettI; 
if qplace=1 then new hedr->sucecessor_chain_head=new 
_item_offset; 
level=level-1; 
go to hack(level); 
top_of_tree: last_new_item_offs*t=nullo; 
new_hdr->first_entry=ansver(1); 
new_hdr->max_length=emax_lereth; 
new _hdr->num_entries=nun_entries; 
new_hdr->nun_free_cells=0; 
return; 
end; 
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APPENDIX G 


THE ERROR HANDLER 


The error handler, GS error, is called via one of six 


entries, each of the basic form: 


call GS _error$entry (error_number, one character_error_ 


code, argl, arg2) 


The error number is printed out and also refers to the line 
in the file of error messages (GS_err_messages) which is to 
be printed out (e.g., error 51 prints out the Sist line). 
The one character code is the internal opcode to indicate to 
the user what operation was in progress. argl and arg2 


depend upon the entry: 


p, pr: argl, arg2 are pointers 
c, cr: argl is character, arg2 is a pointer 


cc, ccr: argl, arg2 are character 


Null pointers are not printed out; i.e., their absence indi- 
cates they were null. 

If one of the entries ending in "r'' is used, the user is 
given the option to return from GS _error. The action taken 
then depends solely upon the invoker of GS_error. In any 
case, the user is given the options of "quit" and transfer 


to a procedure. This is done via the request: 


"Type procedure name, or quit...."' or with return allowed 


wiyo 


The 


aa oe 


e procedure name, return, or quit...." 


procedures most frequently invoked will be db and 


gsdb (see Appendix H). Two typical error cases are given: 


gives 


gives 


call 


GS: 


call 


GS: 


GS errorgp (i211, “U", Iptr, TrptT) 


Error 121 Internal Opcode U 
Pointer 1: 161|232 Pointer 2: 161/420 
Input quarts (pointers 1 §& 2) disagree on choice 


of RSM. Type procedure name or quit.... 


GS_errorg$ccr(221, "G", ent, cent(jj)) 


Error 221 Internal Opcode G 

Name 1: address Name 2: address 
Discrepancy between ent (name 1) and cent (name 2). 
Return yields null result. 


Type procedure name, return, or quit.... 


One final note: typing 'quit'' causes signalling of the 


condition "GOLD STAR", so if the user should desire further 


processing of error conditions, he need only claim this con- 


dition. 


When a procedure name is typed, and that procedure 


returned from, GS_error reissues the request for a procedure 


name or quit (or return, if called for). 


-238- 
APPENDIX H 
GOLD STAR DEBUG (gsdb) 


The utility program gsdb is used to provide a tool with 
which to debug programs written for GOLD STAR. It may be 
invoked as a command, or as a subroutine, and will dump to 
the console four types of items: equivalence vectors, 
quarts, RSM argument structures, and DSM argument structures. 
The latter two are produced by the manager for the RSM's and 
DSM's and are useful to examine when a bug occurs within an 
RSM or DSM. 


From command level, the user types “gsdb". The program 


responds with "ASK!". All requests are of the form: 
x seg|offset 
X can be e, q, «, a, or +. The first four correspond to 


equivalence vector, quart, RSM array, and DSM array; period 
indicates quit (see Appendix E for these structures). 

When invoked as a subroutine, it is done on a per 
request basis; i.e., it is called gsdb$X (ptr) where X is 
as above. 

The quit button can be hit to interrupt unwanted output; 


the command "pi" will resume gsdb at the request point. 
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APPENDIX I 


SOME SIMPLE QUART EXAMPLES 


This appendix is intended to give the reader a few 


examples of each of the basic operations as performed on 


quarts. 
a bog a boc a b o¢ 
1 2 5 q 8 9 i 2 3 
Cl og @ “MPEOM fo ay (42 : 4 5 6 
7 8 ) 13. #14 #15 7 8 9 
LO 1. 42 
1a: Aa AS 
a bos a bi o¢ a bi os 
(2) union 
4 5 6 i 2 3 1 2 5 
4 5 6 
a bi¢ b ¢ a-note thea b ¢ 
sort 
1 2 5 Z 5 1 1 Z 3 
(3) 4 5 6 7 8 9 : a. 7 38 
LQ: te Ee t2 be. “ak 
(See also sort examples to clarify -- the second quart is 


sorted before union is done to the order a-b-c.) 


a “bo <¢ a boc a boc 
3 2 3 7 8 9g 7 8 9 
intersect = 
2 a ee io 2F 42 


& 8 ) oe 4* aS 


bober 


pee} 


Prerenece 


he 


wT 


re 


a 


a 


le 


a 


‘o) 


oN 
~I 
¥ 
"ee 
e 
feo 
“+ 
be, 
G 
~ 
$ 
QD 
ae 
~ 
OO 
o) 


fey 
(4 


ed 


fa 


bred 


Se 
poy 


KO 


os 


1c; 


) 


wa 


wn 
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2 “b & bo a2 ¢ boa ioc 
1 2 3 sort 100 101 102 2 1 5 
ie i Oe 4 5 6 (with respect to) = 5 4 6 
7 8 9 8 7 9 
a 1b c¢ b a abe 
1 2 3 100 101 102 3 2 1 
(12) 4 5 6 sort (w.r.t.) = 6 5 4 
7 8 9 9 8 7 
a bio¢ a De a ob oc 
CiS)- J 2 3 successor 7 8 9 = 10 11 12 
4 5 6 
(14) 7 8 9 successora b Cc a bec 
10 Jl 12 5 1 7 = 4 5 6 
(15) successor a b c¢ a b c¢ 
10 11 #415 = 
(16) successor a b ¢ a boc 
1 1 1 = 1 Z 3 
Note: The following operations will dutomatically sort the 


second argument with respect to the first in order to per- 
form the operation (see example 3): union, intersect, 


difference, successor relation. 


(17) 


@ 
jo 
{a 


get_ent 1 2 3 = (3) a b c (equivalence vector) 


(18) 


Cea 


(21) 


jo 


pee 


— 


ia 


G1 


modify ent 


modify ent 


clear ent 


PYOPCEU sy) 


oO 
a 


PrOoTece CS) 


project (47: x5 


10 


(3) x y 
(3) GG 
a ob 
1 2 
x ini 7? Zz 
Gg tris ttte 
x Y. 
3 
5 4 
7 10 
10.015 


: Sar 
= ] 2 Ss 

x bo¢ 
= } 2 3 


1a 


5 where all 
PENT's = null 


xX 2 

= ] 3 
] 4 
i 5 

= 8 
1 

= x 6 
1 2 
1 3 
1 4 


composition using 


equivalence vectors 


(24) null vector ptr = a 


(25) (Oo) mmep & 


(26) (6) mmimp 


C2 Ge ee Eee 


(28) (6) mn i & p 


Other operations do 


usage. 


rom 
{a 
56 


9 10 8 7 


5 6 4 5 


= 
1 
% 
= 
ike 
{~< 


ry 
i 
WN 
bo 


PS. GES. ae 10 


not lend themselves 


tx 


10 


10 


to simple quart 
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